It isn't really brought out as much in the article as it should be ...

A key thing like about this architecture is it gets some of the benefits of microservices (codebases can be split, services deployed and managed separately, low coupling as a default) but without the downsides of fragmenting the data store, which causes a lot of the issues in a pure microservice architecture.

Once you fragment the data store you now have to fully compensate for the loss of transactional integrity at the data layer. It also forces a coherent data model across all the services - no more "service X" has a slightly different model of a data type to "service Y" - there literally is only one definition of the data type.

So I see it as a reasonable midpoint between monolith and microservice that gets most of the benefits of microservices without the most severe drawbacks.

In my opinion (to summarize) this solve one of the main problem introduced by (wrongly implementing your microservices/ splitting your monolith) which is data intrgrity there is a reason why many cloud services are "eventually consitent" (no wonder the head quartes for such are located in such leftiest cities since its obvious they like the word-playing. By adding any modifier to "consistent" they are telling you it is NOT consitent, even if that is for a "brief" period of time).With this aproach you centralize your data and implement multiple actors working atop the same set of data; as they say in the article this comes to its own costs, mainly due to the limitations of existing ORM's (see https://blogs.tedneward.com/post/the-vietnam-of-computer-sci... you can jum onto "vietnam and OR mapping" to save you a bunch of historic bull crap) where then you have multiple applications working on the same set of data you go onto a more horrible place than data integrity issues, which is data corruption issues... In brief, choose your own poison, you like debugging the DB/data issues, debugging your apps, or having an un scalable system?

What about limiting ORM masochism and making applications interact nicely through the kind of "data access layer" the article discusses?

Then develompen velocity goes down the drain :/ (which grows exponentially more unmanageable the more developers/applications you add to the mix)

In my opinion what you suggest would be a good solution... But try to pass that by mos. Manager for which (in most companies) we are already late to compleate the newly received feature/requirement

But "development velocity" is velocity at doing things well, not at all the same kind of velocity as the velocity of a truck flying out of a sharp turn because the driver likes being fast and dislikes braking.

A sound architecture (admittedly unlikely) would help the kind of incompetent organization you allude to to maintain order and fail later.