I would actually put it exactly the other way round.

If you don't have a crystallized architecture yet, prototyping with a monolith is faster. You don't have to make the cuts (this belongs to this service) which are expensive to change later (unlike moving classes between modules).

Doing internal Java/.NET/whatever interfaces is easier than introducing external API (and associated infrastructure complexity, authorization, routing...), they are much easier to tweak. You have transactions, don't have to deal with a lot of asynchronicity, network overhead etc. For a prototype, I'd always rather do a monolith.

How do you lower risks of adding and removing feature if you need to not only need to add/remove the feature but also decide which service it goes in, set up coordination, and manage networks between the services? That's more work, and more surface area.

Actually for a big codebase there are always reasons to use microservices: much better scalability, easier to develop using small teams, easier to maintain, the software is more robust.

There are even more reasons to use a monolith, or to simply use a service oriented architecture.

Probably not necessary to repeat here, but microservices add a lot of complexity due to asynchronicity, limited interfaces, and more complex error handling.

I mean, can’t you decouple your modules inside a monolith just as well, if what you’re looking is to mitigate the risk of removing features?

Sorry, but that's just too rich.

If you don't know how to design schemas (extensible, modular, ..) and don't know how to design coherent APIs around that, then yes, go Microservices to mitigate the risk. The risk here being the likely chance that you got the schema wrong and end up hacking around it in your "monolith" [almost always sic].