On the other hand, if requirements are mostly defined from a UX/UI workflow and and business logic perspective, that's a whole other story. Then it's easy to justify testing everything, as the expectation that the requirements will change is fairly low. Unfortunately, most companies don't follow the correct way of building software because it requires extra upfront time and resources.
1 - e2e tests for flows and interfaces that are less likely to change.
2 - write unit tests for core models that are specially difficult to test e2e or core models with complex business rules (if it's a backend code, usually your db table with the highest number of relations)
However, in quite a lot of common scenarios, e.g. a simple user-facing CRUD webapp, none of the custom content functionality is expected to be stable enough, it's all still in flux (and thus any unit tests would have to change at every iteration); and all the components where from the beginning it's clear how they should work (e.g. user authentication, sending of email notifications, etc) aren't really custom, so they're already written and tested, you're going to simply use them from your framework or standard libraries.
On a new/fast evolving product I prefer to have a solid suite of integration/e2e tests and a lighter unit test suite near the edge of a server with no mocking of deps (e.g. if it uses a db, spin up a local instance). I would also test something that is non-trivial to understand or a critical dependency in the system e.g. a rules engine.
The reason being is - the code is in so much flux that the internal interfaces change constantly. In agile new requirements come along and you end up chucking a lot of the old code out of the window and wasting time.
As you move towards completion of the project and the internal interfaces shore up then increase the tests. So when it’s in maintenance mode someone else can easily make modifications and has documentation on maybe why something works in a certain way