I think one of the reasons why so many devs immediately want to jump to microservices is because they haven't learned how to architect an application well and have been burned by entangled responsibilities. E.g. many Rails apps, if you're not super disciplined, devolve into a hot mess where your database is everywhere (even in your views), tests take forever to load because there is no isolation, framework updates take forever and so on. Other frameworks like Spring are a bit less bad, but they still don't force you to write properly layered architectures, use domain driven design, etc.
Of course, the idea that this is magically fixed if you split things up into smaller services, is a bit misguided. Yes, API contracts are more explicit (especially in dynamically typed languages where you otherwise lack any sort of contract between pieces of your application), but there are still all sorts of implicit dependencies. At some point, someone might say "ah let's have service B also use the database of service A because of this one feature", or, "you can only call this service after you have called that other service in exactly that way" etc. and then you slowly start creating that distributed monolith...
Of course, the idea that this is magically fixed if you split things up into smaller services, is a bit misguided. Yes, API contracts are more explicit (especially in dynamically typed languages where you otherwise lack any sort of contract between pieces of your application), but there are still all sorts of implicit dependencies. At some point, someone might say "ah let's have service B also use the database of service A because of this one feature", or, "you can only call this service after you have called that other service in exactly that way" etc. and then you slowly start creating that distributed monolith...