I worked on a pretty big Flask codebase (certainly bigger than the one mentioned in the article, though obviously it depends on how you define it, how you structure your codebase, etc). We didn't really use much in terms of third party add-ons, but we did fork and add various useful features, conveniences, etc. I don't personally think the lack of (eg) sessions is very painful, because it's trivial to implement, and there's something to be said for having a code path that you understand. Yes, we spent some time building some pretty generic stuff... but it was a tiny fraction of overall development time, and we gained wins from the fact that we understood our codebase very well thanks to it.
Definitely a balance to be struck, but I really appreciate that the surface area of Flask is small enough that provided you accept the basic conceptual model (request per thread, entry point is a function, etc), you have a lot of freedom to do what you will, and there's very little bias in the system pulling you away from that. Whereas if you don't want to do something the Django way... well, there's some cost to that choice, usually.