There's maybe 20 companies in the world that benefit from this kind of architecture. Everyone else is just being an architecture astronaut or inventing for invention's sake.
Spliting it in managable hunks, that can be modfied independently and do not depend on framework, libraries and other 3rd party code minimizes headaches greatly, when customers want to overhaul some part of the business processes.
From time to time, someone says "it's to complex" which tipically means "Framework I like has this opaque feature which saves me two hours of work and you don't allow me to use it". Yet in the long run math is clear.
Of course it is tool and should be used for the right job. If something is CRUD, just use your favourite CRUD generator and do not pretend you need rocketship.
e.g. i've seen a gigantic technical mess created in a small company with less than a dozen staff -- that required a year of engineering effort to remediate -- because the application code of the company's product was not written to decouple the product's internal domain model from the external format controlled (and changed) by the first customer.
Hexagonal works where you have a big solid core of complex stateless business logic but thr fact that it's very common to NOT have this and hexagonal presents itself almost as a panacaea makes me hate it a little bit.
On the other hand, these "clean architecture" blogs paint this ungrokkable colossus as a northstar -- they contrast it with issues like yours, and present this as the cure to every problem you've ever had in software. I just don't think that's true. None of these blogs ever highlight the loss of understanding. As you approach this style of engineering, you have so many layers, dependency injections and "oh and btw also this" style cross-cuts that no single use-case i.e. codepath can be understood by single person. You're just writing small units of code and hurling them at the codebase, hoping they enter the black hole's orbit and do what you want them to. I like to think that's why Uncle Bob uses huge, unexplorable celestial bodies for book covers :)
P.S. as a counterpoint to your example, I work at a company that's infatuated with the idea of microservices, with little consideration of the tradeoffs involved. A while back I had to add a feature to a new microservice that had been a few months in production. After a couple of weeks of wading through the ports and adapters, DDD-inspired architecture, I realized two things: one, this "service" is just exposing CRUD operations on a single database table with zero business logic in the middle. And two, the Data/ORM adapter layer of the architecture does not work. The migrations are never executed, the DB entities are never mapped, and SQL queryies never fire. Looks like nobody used it since it was first deployed :)