You mean the engineers that have rolled out multiple monoliths and microservice architectures across different teams with different backgrounds, all the while k

You mean the engineers that have rolled out multiple monoliths and microservice architectures across different teams with different backgrounds, all the while keeping careful track of expenditures? I'm sorry, these people do not exist. People are going to eyeball and wing it, based on personal preference and their gut feeling. Dress that up with good-sounding arguments and maybe even some metrics and you have all you need to convince the stakeholders - who almost certainly don't understand the issue at a deeper level, nor do they care to. It's also made more nuanced by the fact that people talk about different things when they mean "microservice". Anything can be split up into arbitrarily small services. This is attractive from a management standpoint, because you can assign engineers in a simple manner without too much crosstalk. Most likely, nobody will ever bother to check if you're spending 10x the engineering resources to do the job. In essence, I can wholly recommend microservices to engineering managers who want to take full advantage of Parkinson's Law.