Not using/allowing Python code in HTML templates is a deliberate Django design decision. We created Django in an environment where the designers didn't know Python (or much programming, in general), and it was much simpler to explain a simple template language than to teach them Python.
Aside from that, there are some nice benefits to having a separate template language. One benefit is the extra level of security -- a designer can't bring the entire site down by making a syntax error in the template. And there's the benefit that it encourages you (rather firmly!) to separate logic and presentation. In my Django applications, I'm never tempted to give templates any logic that isn't strictly presentation-related.
Then there's stuff like the template system's automatic HTML-escaping, which we just introduced in the Django development version. Sure, I guess you could do that with a pure-Python-syntax template system, but it seems like you'd end up hacking things substantially to get that to work.
And, finally, if you don't care for Django's template language, you don't have to use it. The whole framework is just Python, after all -- import whatever external libraries you want to import.
As Mike Vanier has noted (http://www.paulgraham.com/vanlfsp.html), "LFMs [languages for the masses] deliberately restrict the abstractive power of the language, because of the feeling that users 'can't handle' that much power. This means that there is a glass ceiling of abstraction; your designs can only get this abstract and no more." In this context, the Django template language appears to be an LFM. In Mike's nomenclature, embedded Ruby is an LFSP (language for smart people).
It may be that an LFM is the right design decision in some contexts. For others, an LFSP is better. For my purposes (and please forgive the pretension), I prefer an LFSP. And, while you can use an LFM in Rails (e.g., the Liquid template language), I don't see how you can use an LFSP in Django---at least, because of whitespace, not the LFSP called Python.
Well, it doesn't just appear to be an LFM, it was explicitly designed as such.
I don't think that the Python syntax is an inappropriate choice to be used as a fully enabled template language - you could bolt on <% end %> tags with a preprocessor that indents automatically pretty trivially. Such a template language just doesn't exist yet.
It depends on the type of the error, but most errors fail quietly in Django templates. For example, you can pass a Python object to your template, and can reference its fields using syntax like
{{ object.absolute_url }}
if, for example, you tried to access a field that doesn't exist
{{ object.doesnt_exist_field }}
then it simply doesn't emit anything (as opposed to failing loudly).
There are a few errors in the template language that do fail loudly, and these fail when the templates are compiled (something you have the easy ability to test by simply loading the page once on a development server. Or by writing unit tests with the Django testing framework to make sure that all your urls are returning non-error response codes). Anything that has to do with the specific context of the page you are loading (the specific instance of an Object you are looking at, etc) may cause some ugliness (blank space where you wanted to print the value of a non-existant value), but the page will still load properly.
So, answering your question, there are a few types of syntax errors in the template language (loading a non-existent template library, improperly using tags or filters) that can cause errors (but all of those errors are easily testable). But the vast majority of errors will simply be ignored and normal functioning will continue.
Aside from that, there are some nice benefits to having a separate template language. One benefit is the extra level of security -- a designer can't bring the entire site down by making a syntax error in the template. And there's the benefit that it encourages you (rather firmly!) to separate logic and presentation. In my Django applications, I'm never tempted to give templates any logic that isn't strictly presentation-related.
Then there's stuff like the template system's automatic HTML-escaping, which we just introduced in the Django development version. Sure, I guess you could do that with a pure-Python-syntax template system, but it seems like you'd end up hacking things substantially to get that to work.
And, finally, if you don't care for Django's template language, you don't have to use it. The whole framework is just Python, after all -- import whatever external libraries you want to import.