You really can't compare the level of complexity of HTML vs. assembler or microcode, especially as HTML has no control structures like a for, a while or a setjmp.
Now, if HTML were not so easy to parse-at-a-glance, then you could had a point.
Also, there is a simple solution to this problem -- a program that converts $foo into HTML and a program that converts HTML into $foo. pandoc is an example.
If I have both web designers and programmers on my team having them communicate can most certainly be my problem (or at the very least a problem I am gravely effected by).
I'm not talking about zen-coding or pandoc or any tool specifically, you can make the same argument for e.g. clojure vs java: as much as you'd like to use the shiny new tech, you must at least consider the fact that it's a hell of a lot easier to find x new programmers that can use java proficiently than even x/10 that can use clojure proficiently.
It doesn't mean it should be the overriding deciding factor, but the cost of retraining/learning should at least be taken into account when making that decision.
If something is so cumbersome that it needs to be abstracted away, do it right. It's really fun to press a few keys and watch a bunch of code show up, but it's even more fun to not watch it show up. Because then you have something that's not a write-once operation.