I personally see django vs flask (or other microframework) as this:
- Use a framework that has adequate components that are well integrated and quick to get off the ground, but where you might hit snags with the bundled components later and have to monkey patch them to continue working within the framework.
- Use a micro-framework where you can choose to glue in excellent components (SQLAlchemy, for one) at the cost of the time spent writing glue code.
I personally really like django. Even though it is considered monolithic, I agree with a lot of design decisions and a lot of the components are "just the right amount" extensible. Most of the third party apps that I use work well.
That being said, I'm using flask now and enjoying it :) I hit a snag pretty early with django's ORM [1] and couldn't figure out a way around it other than raw SQL. SQLAlchemy's flexibility won out in the end. I chose flask over other micro-frameworks because of its documentation, extensions, design decisions, mailing list seemed active etc.
Now that I have switched from django, I'm really enjoying the flexibility of picking up 3rd party modules (or flask extensions) and using them instead of having the decisions made for me. It is very marginally more work than django.
[1] Query multiple tables (books, cds {subchildren of products}) for products that were updated in the last month.
Using an abstract base table (products), django's ORM required multiple trips to the DB. Using a concrete base table meant that getting any single product would require a join. SQLAlchemy handles this scenario with unions.