"Not only were the various teams all competing for the same deployment resources, it meant that every time an "Incident" was declared, several teams' code had to get rolled-back; and, no team could deploy while an incident was being managed."

So, how exactly did switching back to monolith solved the above problems? Seems to me like your actual problem is in QA and managing releases than application architecture whether it's towards or away from microservices. What I'm hearing is that you decided to fallback on relying on people to not push broken code out to production. Which is fine and all but what are you going to do if your team grows again? Rearchitect the system into microservices? A little heavy handed don't you think? In your particular case, I think, be it monolith or microservice architecture you need to work more on improving QA and streamlining releases. These, once automated, don't depend much on the number of developers. I've experienced this with a team of 3 as well as a team of about 15 (not 30 though). I don't think that the application architecture has anything to do with your problems one way or the other.

Having said that, if the late night calls stopped after this exercise, then that's fine because no one should have to go through that!