The main reason is so you can statically analyze the template source code. For example, pair Gumbo [1] with an HTML-based templating language and you can identify every image referenced in the HTML and automatically coalesce them into a sprite sheet. You can replace dynamically-generated images with data: URLs and load the data at the end of the page, minimizing latency. You can validate your templates to make sure they never generate invalid HTML. You can run any inline scripts found through Closure Compiler or Babel to minify them (or, in Babel's case, support ES6 directly in templates). You can do CSS renaming automatically on all elements.

A secondary reason is to constrain your users so they don't end up writing constructs that will be impossible to manipulate with tooling. Early in Bazel's [2] history at Google, BUILD files were just ordinary Python, and you could use any Python code you wanted, and all that mattered were the calls you made into the build rules. This worked great, with people writing all sorts of list comprehensions and conditionals to minimize code duplication. And then tools came out to reformat BUILD files, and automatically query for dependencies, and detect dead binaries, and all sorts of other cool stuff. The tools were a lot more useful than the ability to include arbitrary code, but (because of the halting problem) they would choke whenever they encountered arbitrary flow constructs. So now arbitrary code is limited to the portions of the build system that explicitly allow it.

The EDSL approach (where you just use a regular programming language and a bunch of calls into the engine) can be a good idea, but you give up a lot in tooling. Usually it's most useful in the early stages of a project, where you don't have manpower to write the tooling anyway, and then becomes a legacy hassle as you assign more engineers, write more code, and get more leverage from writing tools.

[1] https://github.com/google/gumbo-parser

[2] http://bazel.io/