Just sandboxing what changes themes can make to the behavior of the system would be a win. As far as WordPress is concerned today, there's "themes" and there's "plugins", but there's no separation of what those two things can do -- plugins can change the site's look and feel, themes can change how the site (and WordPress itself!) works. As far as WP itself is concerned they're both just big bags of PHP code that can do anything PHP can do.

That leads to all sorts of debugging fun when something weird is happening, and opens up naïve users who assume that a "theme" is somehow safer than a "plugin" (because all themes do is change the look and feel, right?) to security risks from downloaded or hacked-up themes.

This is a very good point. Sometimes those "quick fixes" really aren't the best idea, I myself used to "hack" so much stuff in Wordpress when I was using it, and yes I solved whatever problem I was having at the time, but a few updates later it would come bite me in the you know what.

So much of programming is protecting the programmer from him or herself. By enforcing rules you protect yourself from bad habits. I think a separate template system and keeping the view separate would help keep everyone honest.

Eventually I started to do my modifications as plugins, which is one area where Wordpress really shines. Other systems could definitely take note of the way WP handles plugins.

Somehow I expected, the valid argument against business logic mixing inside templates, making the case for a template language. I agree, but that way we are progressing towards dozens of languages in implementing a simple user function. For example, why not a language for controllers, and another one for models too?

In contrary, I am in the pursuit for the one universal language to be used everyhere replacing, javascript, html, css, templating language, ruby/python/php, sql..

You'd probably like Clojure.

As an aside, though, part of the reason we have different languages for things like backend code, markup and styling is that they're commonly done by different people with different specialties. A general-purpose language will not offer much benefit to a designer, but it will trip them up more often. Having a language tailored to your specialist is a good thing. The only time you'd really want everything done in one language is when the same coders are doing everything. I admit I'm in that situation very often, but it's more maintainable if you just use CSS or similar so that normal front-end guys can work with it.

That makes sense. Ideally it would be nice to have one common elegant language which can do it all. But I doubt that any one language can do everything elegantly. The syntax of some languages make them much more elegant for certain purposes. For example compare XML and JSON. JSON is great as a lightweight way to represent simple objects, but XML is better for representing entire HTML documents. Likewise you can do all your CSS stuff by manipulating DOM properties in JavaScript, but pure CSS is a cleaner and more readable way to do things because it only does styling statements. (Unless you go out of your way to put logic into your CSS.)

The bigger the project is the more you have to favor readability and maintainability first, and using multiple specialized languages to accomplish different specific tasks is an effective way to keep the codebase readable and maintainable.