What can you not do in a monolith? You can still have async queues and different event processors that stop and start independently within a monolithic deployment.
Speaking as a monolith fan, IMO/IME the main drawback is RAM usage per instance.
You can have a "big, beautiful" Rails monolith codebase used by both Puma and Sidekiq queues etc, and that works well from most standpoints. But RAM usage will be pretty high and limit horizontal scaling.
Sure, you can get 32GB of RAM for less than $100, but that's not the relevant thing to think about.
Think about it from another angle. RAM is expensive when you're talking about cloud infrastructure at scale.
Or, think about it this way.
For a given compute budget, I can run X instances of Rails, or X times Y instances of a framework that uses less RAM. 100 instances of Rails versus 300 instances of Express or whatever.
Now, it still might be worth it to run Rails, because developer time is more expensive than cloud infrastructure. Or maybe you don't really need to scale. Or you could skip the cloud infrastructure and go bare metal, which is what Basecamp does last I checked.
If by monolith you mean multiple processes that you can control separately, each with their own memory state, you can do anything you want with it. That's essentially multiple services.
You can have a "big, beautiful" Rails monolith codebase used by both Puma and Sidekiq queues etc, and that works well from most standpoints. But RAM usage will be pretty high and limit horizontal scaling.