Jinja2 is indeed much faster and offers a more flexible expression syntan than Django's template engine. However, Django's native template engine has one huge advantage right now - when there is a syntax error in the templates, it almost always gives informative errors the correct location. Jinja2, as it is right now, often gives no errors and completely wrong locations for the problem. This has been a serious disadvantage for me when dealing with more complex templates. This is surely temporary, but is the state of affairs right now.
The speed of the template engine isn't really the problem (it's unlikely to be a major bottleneck anyway, compared to database operations).
It's the restrictiveness compared to e.g. Jinja2 or Mako. With those engines, I can just drop in a Python function and be done with it; with Django template engine you end up writing tons of template tags for the simplest things. It's designed for a particular work environment (designers work on templates, so should not be allowed to do anything dangerous) that I've found to be quite rare in most projects.
I think if your writing more than a couple template tags and for simple things you're doing it wrong. I would really limit templates to being primarily HTML. Put any advanced python functionality in your view function, Django templates are minimal and not for making queries like other templating systems (a good thing IMO). If you need to do anything crazy advanced like recursively display stuff for items, don't write a template tag, use a simple include tag to insert HTML for subelements. Using the include tag when possible is also great for AJAX, as you have the HTML for a subelement sitting in a file if you want to render just that to return to a XML request.
I was not implying that the concept of recursion is at all advanced. I was implying that the problems to be solved in the template layer are very simple.
I won't be able to come back to you because it would be too inefficient doing something more advanced than that in the template layer. Because rather than write the python to write template syntax to be interpreted back into python, I simply wrote the logic in one-pass python in the view function. It's more direct, runs faster, and your templates are clearer to designers if you're working in a group project.
I've also never seen a project where the templating engine was a noticeable part of performance. I did see one where the decision was made to switch to Jinja2 which brought a huge amount of work duplicating a bunch of existing Django template tags – which didn't make much of a difference in the face of the 8,000 database queries needed to generate a page.
The ORM has quite a few failings. Granted I like the API, though the backend code is nothing short of a cluster-fuck.