I think you're confused. The PHP snippet was to demonstrate my point that:
- The path of least resistance in PHP is often directly at odds with the "proper" way of doing things (including many things listed in this article).
- This is important because PHP's intended domain is Web development, so this can easily cause security flaws.
- Any attempt to "fix" this example will inevitably make it longer, more complicated, harder to remember, etc.
Your PHP "hello world" does not demonstrate those problems, since it has no XSS or HTML, so it is a poor example.
After this demonstration, I abstracted to the more general concepts of "path of least resistance" and "'proper' ways to do things", irrespective of language or domain.
To clarify my meaning for these phrases, and to demonstrate how language designers can use the former to push the latter, I gave two examples: Java pushing its preferred approach of class-based OOP, by disallowing raw, top-level statements; and Haskell pushing its preferred approach of monadic I/O, by enforcing the type of `main` and restricting the available APIs. Notice that neither of those examples make the "proper" way easier (that can be very difficult, in general); instead they eliminate anything that's easier (like top-level statements), such that the "proper" way is the easiest thing that's left. In other words, Java's requirement that even "hello world" be wrapped in a class is a good thing for Java programmers, since allowing top-level statements like `System.out.println("hello world");` would undermine the principles of the language. This general argument is not specific to PHP, and certainly not a direct comparison to the XSS snippet.
After defining and demonstrating these general concepts, I then returned to the specific case of PHP, to point out how backwards-compatibility with its legacy of easy, insecure approaches undermines the attempts to improve the situation. In other words, the "proper" way to write PHP (at least, back when I used it) is to use OOP, namespaces, type hints, escaping of user input, etc. Yet the design of the PHP language discourages all of those, by providing easier alternatives which are "improper" (like in my XSS example); and removing those alternatives (in the same way that Java forbids top-level statements) would break almost all existing PHP projects and require the majority of PHP developers to change their habits; and doing so would eliminate PHP's main selling point (installed base and developer mindshare).
I hope that clarifies why the comparison is not disingenuous (i.e. because I'm not making the comparison that you claim).
If I were to make a comparison of that vulnerable PHP code against something else, it would need to be against a language which is primarily designed for Web development (to avoid being disingenuous), and it should be designed to make the "proper" approach the easiest. The Ur/Web language fits these criteria nicely, and (from a quick skim of the tutorial at http://www.expdev.net/urtutorial/step1.html ) the equivalent to that PHP would be:
fun greet data = return
Hello {[data.name]}
Not only will this will perform the correct escaping, it will also be a type error if another page tries linking to this one without giving a `name` parameter.