I agree, but aside from it being seen as "cool", what drives some engineers to go microservice first architecture is having experienced the inability of an orga

I agree, but aside from it being seen as "cool", what drives some engineers to go microservice first architecture is having experienced the inability of an organization to acknowledge that they actually do need to re-write a monolith as two or more services or undergo a general re-architecting of the monolith. Getting buy-in from the business is extremely difficult as clearly communicating the actual effort and impact that re-architecting the monolith would require is nearly impossible. This is usually due to poor separation of domains via lack of modules within the monolith, spaghetti code, circular or other strange dependency trees, tables with relationships or data that should never have existed in those tables, and a whole other set of other bizarre issues that were due to lack of planning and general discipline by engineers along the way. If you have a microservice first architecture, the perception is, it's easier to describe effort to re-write an individual service or split it into two services as there is a clearly delineated body of work. Bizarre service-to-service dependencies may still exist and a poorly implemented microservice architecture is still a potential challenge. Point being, organizations incentivize bad economic decisions on the part of engineers through the inability to recognize that rework is a necessary aspect of developing software and by constantly eschewing rework in favor of feature delivery it sends a strong message to the engineer about what to prioritize.