b) Maybe the commenter has only worked on small applications but I've worked on enough million line code monstrosities to know that one change can have far reaching consequences. It is simply too easy to couple components together e.g. be reusing a shared utility or service class and your code coverage will always be lacking in some way.
c) Microservices enable far more resiliency and scalability simply because you can deploy more of the ones that are critical or non performant. A sensible service discovery strategy can make this a one button, trivial exercise. Doing so on a complex monolith is often far from trivial.
d) This idea that your entire system goes down if a microservice goes down indicates your architecture is flawed. You should be able to still operate in a degraded state or at least provide some functionality.
e) If you can't test your service independently then your testing strategy is flawed. You should be able to trivially mock/stub out any dependencies and if you can't then you need to rethink your API design and the nature of your coupling.