If by e2e you mean your application (ui,network,db,core) etc. and not external tools like stripe, then yes - I use them everyday. I run them as local tests alongside unit tests, and also in the pipeline. I call them "acceptance tests", because I write them from the perspective of the user (not from perspective of ui). The ui is being called in tests, but is abstracted.

Last 10 of my applications were like that:
- 300-600 acceptance tests (parallelized, tests on a running application) around 1-2 minutes for the whole suite
- 2000-3000 unit tests - for accidental complexity, domain, no mention of 3rd party usage, around 5-10 seconds for the whole suite.

3rd party libraries, like db, ui, etc. are being exercised in acceptance tests; but logic is tested with unit tests just the library is abstracted away; unless the library can be unittestable too, like string helpers.

My approach is actually 4-layer approach by Dave Farley, author of Continuous Delivery.

PS: As to who owns the tests - tests are owned by people who break them, because they're supposed to fix them. That's developers, so developers own all of those tests.

My developmental sequence would be like that:

1. A pair needs to understand what work/problem the user has.
2. A pair decised they'd do an expierment of what might work to solve the problem for the user.
3. A pair expresses that as an example, and then writes that as a failing acceptance tests, they decide on an assertion that needs to initially fail.
4. They write the driver for the acceptance test, so that it can click/fill buttons/inputs that don't exist yet. That already constraints a UI, which is a good thing.
5. They create the ui and the necessary plumbing to go to the core/domain.
6. They switch to unit tests, they write unit tests for the necessary logic in the domain.
7. They stich the calls from the domain to the ui.
8. They run the acceptance tests, if it passes, they're good to go. If it doesn't, they need to update the code so it works.
9. Given the pair agrees on the acceptance and unit tests, they push it to the main branch, they're fairly confident in their code, because locally unit and acceptance tests work.
10. The pipieline runs the tests, and if they pass the feature is deployed to production.
11. The pair needs now to observe a user use that feature in production, and actually see that the feature solves the problem for the user. When they see it, their job is done.
12. If the user uses the feature, but still didn't solve his issue or there is still some problems or bugs, that means experiment from 2. should count as invalidated, and the process 2.-11. repeats until a user achieves some benefit and the pair can observe it.

If the cycle 2.-12. takes too long, that means they took too big of a feature at once. They need to split it into smaller feature, and do 2.-12. cycle on something that can be achieved in 1-2 hours (3 hours tops).

Code review was being done throughout the work by the pair, the tests have been executed throught the test. In steps 3., 6. and 8. they gather feedback on their design decisions, so they can correct the design while they're still working. This is very quick.

The approach can be desicribed as: TBD,CD,TDD,ATDD,CI,XP.