I've trended towards feature oriented hierarchies over type of thing hierarchies as I find they tend to be simpler, easier to replace over time and often much easier to maintain than separating DAL/BLL/SVC/VM/M/V layers etc. I really don't mind if my endpoint file sits next to my database access file, next to my validation file along with the test files for all of them in a single directory for a given feature. The feature is the concern, not the fact that you have a web endpoint, or need to talk to a database.
They're also easier to manage in a monolith and break apart as needed without having to replicate the jungle for want of a banana.
Worse still, is the variance and onboarding for each customer was taking roughly twice as long as the previous one... I left during the dev cycle to bring in the 4th client. These were state/county agencies, each with slightly differing requirements. I was in charge of the UI and the API for the UI... putting all the logic inside the DB itself was emphatically NOT my decision.
Looking at and having looked at some of their cloud spend etc, nah.
To be more specific there's a lot of fat. Whether that's HFT style high performance is a different story.
I've only ever had to debug spring DI once, I'll admit it usually works. But when it doesn't..... All those proxy objects will drive you nuts!
It's a very clever solution really.. And that's the problem! You don't want to build your servers on a clever foundation, you want a simple one!