The thing is that actually very little of this is unique to Django. The types of tools you need to deploy dynamic-language-based web applications don't differ depending what the "P" in LAMP stands for.

That maybe true (Capistrano which you reference was pulled out of 37 signals) but I think my general criticism still stands (+ standardization in and of itself has benefits in that it helps people help each other).

The rails community from the beginning has had a more holitstic view of the problem it is solving.

The third tab on the rails site is about deployment. There are three performance monitoring companies and 6 different rails specific hosts.

Other examples: db schema evolution (migrations) and rake tasks. There is also a litany of useful maintance tools you can find on github.

This is not just in reference to code either, its everything else too, including documentation.

I like django, I prefer django, but in this one critical area, the last mile, rails does better. And its frustrating because its not a hard problem.

sessions are in contrib, not part of the framework.

Some of the testing stuff is "in-house".

It's not even close to true that everyone's deployment is (or should be) very similar. It's a bit more arguable that everyone's testing should be similar. But forcing one way is not the Django way and one of the big reasons it is loved.