Others have covered good, general rules of thumb, but I'll go into a few specifics for why I generally avoid microframeworks. I've spent quite a bit of time with Rails, and whenever I try a microframework I'm
immediately aware of all that Rails does for me - for free! Here's a few things I had to set up:
1. Configuration: This is way more important than you'd think and very difficult to get right. Consider storing aws credentials etc - Rails has a great, in built pattern for storing and accessing them, and the initializers pattern allows you to load them without contaminating the rest of your codebase with it. Plus, environment specific configs - especially env specific db configs - are super tight to have for essentially free.
2. Logging: more of a pain to get right than you'd think! Rails gives you an easy way to log anywhere, environment specific logging rules, logging to file and console and other such nice to haves.
3. DB access: You don't have to think about setting up connection pools or an ORM - it's built in and pretty capable. With microframeworks you have to hand roll the entire db access layer.
4. The glue: this is the biggest thing. You'll know it when you're three weeks deep into building a "micro" service and you realise you've essentially made Rails in Sinatra, except worse because it's buggy and poorly documented.
I love toying around with microframeworks - it's the best way to learn what goes on behind the scenes of a complex framework like Rails - but unless you knoe exactly what you need and why the mciroframework is better you're probably better off with Rails.