My answer? Maybe, probably not.
EOE tests are good when they are very simple. If you are planning to cover basic scenarios, you can manage to gain some advantage with EOE tests. But if you have a really complex and big application (mission critical or not), this EOE tests will be expensive to maintain and you need to know your scenario to valuate if worth it.
Some years ago the Google Testing Blog discuss this subject. I can only agree with the author. A good test needs to be fast, reliable and isolate failures, features that the EOE tests are not capable to deliver to you.
I worked on an application that have more than 12 hours of end-to-end tests covering a lot of scenarios. Eventually we managed to distribute this tests on different machines, controlling the start, execution and ending of the tests, collecting and merging the results. The tested application was a monolith application (what it is easier to put up and running to test) and was nightmare to maintain the tests.
Most part of the time we was maintaining the tests instead of catching bugs from their results. Discover the origin of a bug on a end-to-end test takes a lot of time. We also dealt with a lot of "false-negative" tests and few time to understand the problem and correct it: Java Applet loading problems, expected element not found on the page (plus other problems about the automation speed), maintain query code that are just used on the database memory test (because the original query use database specific code), etc.
All of this need people to maintain up and running. On the end we starting to delete some EOE tests and replace them with many unit/integration tests.
So, my conservative advice is use the testing pyramid from Google:
As a good first guess, Google often suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests. The exact mix will be different for each team, but in general, it should retain that pyramid shape.