(Sorry for the delayed reply, I’m catching up after a week of vacation!)
Yes, good clean code would be easier to pivot with… but in the time it takes for the business side to decide what to pivot to, the dev side can get started cleaning up the code a bit, plus there’s a fairly large chance that the whole codebase will get chucked and rewritten anyway, or that the biz will just go totally bust and not have a chance to pivot into anything.
As for monoliths, yes, it’s an argument for doing things the easy way. Building a monolith, whether majestic or not, is much easier and faster than deciding where to split things up into microservices, and figuring out how to make them all communicate properly. You can certainly start it as a monolith, and tear off chunks to be microservices later. Again, yes, this will be easier with good clean code… but that’s an investment that you might well not have a chance to cash in. You can also tear off chunks in just a conceptual manner, and reimplement the code differently, perhaps more cleanly this time (since it will probably last longer this time).
But that does bring up an idea… maybe a framework based around microservices in the first place? Say for instance we started with Rails but added microservices for various common things to add on, like various kinds of user management, especially authentication and profiles, maybe authorization, into microservices. Or provided a common foundation for making microservices, so if you needed to split off a service for certain kinds of PII or PHI or credit card data or anything else sensitive, or anything else that might otherwise make sense to split out, you could start that microservice from a common basis, much like how so many apps start from the basis of Rails. Think that might be useful?