The reason we're tackling this space is because we don't think this needs to be true of end to end, or even heavier integration tests. They have really awesome qualities such as being able to test close to things users actually care about (which is the most important part of testing at all!), can identify broken pieces across or in between parts of your stack, and are fairly intuitive to write/understand (imo).
But what if we could then build tooling to minimize some of the bad stuff - make tests more stable by providing better debugging, enforcing best practices automatically (imagine we can tell your tests are behaving non deterministically because of X async action, or use X conditional wait instead of a time-based one), and even giving you knobs to trade off between test fidelity and speed (ex. click a button and you can turn on/off network mocking in specific tests so you only exercise a part of your system instead of spinning up/testing the world).
Hopefully if we can nail our vision, you might be saying in the future "why are there so many unit tests? They cover so little surface, don't test how our app fits together at all, and require a lot of maintenance since they tend to test some form of implementation detail or another. We should be doing a lot more integration and e2e tests :)". It'll be a long road until then, but I think developers and users will be much happier the better we can make testing.