The idea is that testing is a pyramid with lower level (unit) tests having high coverage and running very fast.
There would be fewer integration tests that test larger units and even fewer service tests that test a complete artifact.
Even fewer than that would be end-to-end tests that test multiple artifacts in an environment.
An entire application system could have as few as 5 - 10 journey tests that run within a minute and continuously assert that the most fundamental user actions are working. Any failure would be an alarm.
Each level of test has a different focus. I do agree that when a system is 'done' that unit tests have the least value. However a system is never 'done' and there are always changes made to it. If unit tests get in the way of desired refactoring, by all means throw them out and make new unit tests for the re-implementation.
The other good value of having unit tests in your codebase is that existing tests serve as great patterns from which to create similar new unit tests. Finally unit test coverage can also serve as documentation to onboard new developers in a new area where the even just the names of the test cases can help understanding of a component.