When you have a complex monolith, unit tests and static typing allow you to create features and refactor the code fearlessly ("Computer says no" is a good thing here).
For example, a decades old cad product with millions of lines and tens of developers doing parallel changes. The unit tests allow the continuous integration system to dish out isolated reports on failing tests before pullrequest is merged to main, instead of integration test just bombing at some random place.
Unit tests save time.
There are some things that are absolutely worth testing. For example my current project is a library that calculates payroll taxes for US employers. This stuff is self contained, stateless, idempotent, but complex. And yet I know what kinds of inputs are non-trivial and can calculate the outputs by hand, so I can test it.
On the other hand, testing that CRUD form that submits data to S3 as well as saving it in the local database is nearly useless. Run through the form when you update it manually and make sure it works. S3 semantics change rarely, your own database changes would necessitate you changing the corresponding form.