I think unit testing, as well as functional testing, both have a place in any system, but I would say you need to form the base of your testing on unit tests. Simply because it's so much faster, and cheaper.

I have experience on monolithic applications that are over 10 years old and still being developed, and the entire test collection is made using functional tests. Want to guess how long it takes to run all of them? Over 2 hours, at best.

Developers run those tests almost daily to make sure 'everything works', but even those tests cannot, and never will, test each and every possible scenario. This has already been proven on multiple occasions. It also takes a lot of development time away from you, plus it requires multiple resources including, but not limited to, database, redis, system libraries, cloud platform integrations, other third party integrations (many of them)... It takes money to run platforms to run those functional tests automatically, against a database that actually persists that test data. Then you run into a problem with test collision, having two tests manipulate the same thing, so you can't run them parallel and you have to run them in the correct order..

Unit tests are cheap and fast to write, once you know how to design your code so that it can be unit tested. You might have to refactor it, true, but that's why you should wear a functional hat, as well as a refactoring hat. The true problem is that developers don't know what dependency injection is. Once you learn how to do that, you know how to write unit tests that test each part of your function with different scenarios.

Also, you'd want to run unit tests on your deployment pipelines to see if something's broken. It can save you a lot of hurt.