One valid point he makes is: "Confusion on where to put code, and too much flexibility". Can't say how it is in other frameworks, having never used them, but The Django Book had far too many cases of saying "you can do it here or there, it's a personal preference". I don't want to make a choice when I'm new to a framework, I want to be told what's correct and what isn't!
Django unambiguously states where to put your models, view functions, forms and the url patterns. Those are grouped into an 'application', which you can have many and define logically by the general task you want them to solve.
Inside the model, view, form and url files (settings too for that matter) you write your code according to the style and philosophy of Python.
For that reason Django can not and must not define for you in what other file should you keep and what name should you assign to some class you write that is required for one of your views or another.
If you don't feel comfortable with the structure of your Django code, it's best to look into general good practices of Python programming, because Django is Python!
class SomeModel(...): ...
class SomeOtherModel(...): ...
from some.other.place import SomeModel
from yet.another.place import SomeOtherModel
In fact this is another instance of what I complained about yesterday: http://news.ycombinator.com/item?id=1605928 People see the "DSL" and all knowledge of the underlying language goes flying out the window. Models are actually very, very non-magical, and anything that you do that ends up with class in the certain namespace simply is a model, and any Python language feature that lets you produces such a class can be used to make one.
I have used Rails, but my web framework of choice is Tornado; I really like their design choices.
That's why Django's "flexible" approach seems odd to me.