I like the idea of using a proper templating engine for SMF themes. Rather than write one from scratch, using a popular library means that the work is offloaded a bit. I'm a fan of Twig personally, but any sane thing would be great. (Note that Smarty is not sane.) Don't think of it as "still PHP" because it's not. It's more a
Domain-specific language just for templating.
As a bonus, that means you don't need to be a PHP master to create or modify a design. This is a
huge benefit as it means that core developers don't need to waste time helping a design-focused contributor on making changes. For the most part, you can even load the raw template in the browser and since you don't have a ton of PHP in it, but rather placeholder tags, it will display fine without needing a whole SMF install.
Some specific responses to the latest points:
To be fair, it does help to have the HTML properly highlighted outside of quotes, that'd be one of the upsides of these systems, but (at least with those three in particular), you're sacrificing the entire PHP readability/syntax just to not have to do echo quotes, and I don't think that is a good trade.
When you're focused solely on design, does it matter to know that you're having a plain PHP echo, or just to know that certain text goes in a place? I'd argue that anyone focused on design would be happy to not have to remember a bunch of PHP echo quoting rules and would rather just have a placeholder they knew would contain some text.
if you could flip a switch to make echos better and leave everything else the same I'd be all for it, but it isn't this simple
Well, there is the short open tags option, but that often isn't enabled and can interfere with other legitimate tag usage.
The people that need to know HTML don't need to know PHP as well. Which is great if you happen to be a theme designer.
Sure. And the only relevant thing getting in the way of this is the highlighting, the rest doesn't really make any difference in the end, besides make it worse for those who already know PHP having to learn one more syntax. But god forbid the people editing the HTML learn how the system they are dealing with works.
Most of the templating languages like Twig and handlebars are pretty quick to pick up. Also, if you're worried about having to learn multiple languages why are you not concerned about PHP coders having to learn CSS and JS?
As for learning how the system works, most mature things aren't so involved. I don't have to know how a CPU works at the component level to operate one. I don't have to understand crankshafts to drive a car. I certainly don't have to know how thermisters work to adjust the darkness level on my toaster. Why should I have to learn structural engineering to paint my house walls a new color?
Heredocs give you a different problem. You actually make it worse, not better, because you can't have any inline logic whatsoever in a heredoc. It's simply a string. I can have inline logic if I want, I can have partial templates that embed with no extra effort.
Oh, I see. I kinda skimped over it as the indentation is a dealbreaker over other methods. Still, it would be great if there was something that worked similarly.
Templating engines like Twig are the answer. No worrying about jumping in and out of logic code. No worrying about proper escaping syntax. Just write my HTML, stick in the placeholder tags and go.
This is why you separate them.
You can't separate them if you have to both write the code and make said code look nice 
You most certainly can separate them and make the code look nice. The backend code makes the effort to pick the right template files, get the processing done, and set all the strings up for use. Then it calls the templating engine to combine the strings and the design. Both sides look very clean and there's a good separation of the logic and the design.
Except it isn't. You can't insert PHP into those files and still expect it to work - because it won't. It's physically a separate language that's converted to PHP on demand.
Note the "with a different syntax". If it merely gets converted into PHP then it really is no different in the way it works, you just write it differently. If there is something else it does besides this, you've yet to say what.
Well, it's PHP internally. It's not like it's pre-processed into PHP that you'd work on or anything (well, kinda, but that's not relevant for this discussion). The something else it does is cleanly separate the controller logic from the view. It makes
both parts easier to code and read.
You don't seem to understand the issues with not properly lowering the barrier of entry. It's about how it affects the culture around the system after it has been in place, which boggles down to curation, the quality level from the median average output. You lower the barrier of entry, you let the inner workings of the system more distant from the developer. People will develop on top of it without really having the tools for appropriate debugging on the system nor understad its inner workings to properly optimize their work. Like mechanics who don't understand how the car they are working on actually works. You end up with a lot newly developed objects who simply don't fit they system they are working upon. Just look at any mobile app development or the overuse of frameworks to understand what I'm talking about. The same kind of bloated, uneficient coding culture exists around the likes of Wordpress, Shopify, Tumblr, Bootstrap etc. Lots of sleek modern themes, none of them runs well.
Are you actually trying to gatekeep? Are you actually saying "unless you know PHP at an expert level, we don't want your kind"?
As for "appropriate debugging", if the template is cleanly separated, there shouldn't be any fancy tools needed for that. It should work just fine as all you're doing is creating a design and dropping placeholders into the appropriate areas. There shouldn't be any optimzation needed on the logic side, that's all handled by the SMF PHP that shouldn't need to be touched.
As for themes that don't work well, that's more the problem of the HTML/CSS/JS the theme author used than an issue with a templating engine. If the author loads down a theme with a ton of poorly-written JS and a lot of third party JS libraries, and then adds broken HTML on top of that, it's going to run awful no matter if it's expressed in a template engine or in the PHP mess of logic and design. In fact, it just might be worse in the current SMF style because of all the access to the raw PHP that can be abused.
But if you think there is no other way to do the same (after all, the main problem at hand that using a different syntax would solve is the highlighting, which I already said I agree on, depending on how it is done), then I will indeed have fun looking for alternatives, specially since this will benefit everyone equally, from the beginners to the pros 
The MVC concept in which having a separate clean template layer exists has been around since the late 1970s. The use of that pattern in web development exploded in the late 1990s and early 2000s after it became clear that it was a good model. It can speed development because the people working on the UI don't need to wait for back-end work to be complete and the back-end coders don't need to wait for the UI to expose new values. It can let you easily have different templates for different views without having to change a bunch of inline PHP code. Make a mobile-friendly template without having to change the executed PHP. Anything that makes SMF development faster and makes it easier to contribute to SMF is a big win in my opinion.
