Why shouldn't there be many E2E tests?

Because E2E tests are the most expensive, slowest and most fragile of all test types.

#Reasons

1. Slow runs Each test launches a browser, navigates through pages, waits for rendering, and performs real actions. A single test can take seconds or tens of seconds, which is dozens of times slower than unit tests.
2. High maintenance cost The smallest changes in the interface, text, markup or network scenarios can break a test. The more of them there are, the more time goes into fixing them.
3. Dependency on the environment E2E tests depend on the network, the database, the API, the infrastructure. Any instability makes them flaky. Mass E2E = mass false failures.
4. Overlap the same scenarios E2E tests often check similar user flows. If there are too many of them, duplication appears that adds no extra value and only slows the process down.
5. Kill the team's speed Long runs → a long feedback loop → slow decision-making → slower development.

The essence: E2E tests should cover only the key user scenarios. The rest of the checking (logic, integrations, states) is more cost-effective to cover with unit and integration tests, because they are faster, more stable and cheaper.