It's a false dichotomy. The split isn't about no abstractions vs. services, but about whether the abstractions should be behind a network boundary. Let's look at these one at a time.
1) A single syntax error will _still_ break everything in a microservices architecture if the service in question is any essential service. In my experience, most services are essential. In a dynamically linked architecture, the failure occurs when you try to pull in the library. In a well-designed dynamically linked architecture, you can opt to not pull in optional components.
2) If you're an idiot and build everything monolithicly. A well-designed non-services architecture has many independent and independently testable libraries. Integration testing does require the whole system, both with and without services. In this case, both the resource usage and startup time is much lower without services.
3) Ditto for services, if you do integration work. Not so for independent libraries, if you do not.
4) Question of where you put the abstractions, not how you make them.
5) Again, question of where you put the abstractions, not how you make them.
The key reason for services is isolation, failover, and independent deployability.
There are a bunch of programmers out there who were only taught one way to make abstractions (be that services, objects, or what-not), and assume everything else means abstractionless spaghetti code. That's simply not the case. Structured, functional, and other modes of programming have the same quality of abstractions as OO. Likewise for whether you link statically, dynamically, or over a services boundary.