Content Security Policy (as you link) is indeed a "better" solution, in the technical sense; it's fine-grained, supports reporting, doesn't require servers to generate the random "hard_to_guess_string" needed to unlock the block, and (possibly most important) doesn't introduce a new un-XML-like construct into HTML. On the other hand, it tends to be more complicated to use it in real-world web applications, and it's so broad that a lot of browsers have either no support for it or have serious bugs in their support (did you know SVG can contain scripts, and sometimes CSP rules aren't applied properly there?).
Sandboxed iframes are simpler and basically do what you're asking for, except that the content is loaded from an external source or by writing it into the framed document (if same-origin); no need to worry about an attacker terminating the sandbox with a </iframe> tag because the sandboxed content isn't inline with the iframe itself. On the other hand, given how few people actually use them (despite pretty good browser support), the problem may be more a matter of web devs being bad at security than of web devs not having good security tools. Of course, we knew that already...
With all that said, I feel compelled to point out that *just* blocking XSS isn't enough anyhow. Without using a single scripted behavior (just HTML and some simple CSS) I can do things like create a lightbox that contains an HTML form saying "Your login session has expired. To ensure the security of your account, please log in again." with a username/password box, all themed accordingly with the site I'm attacking. Of course, the form POSTs to a web server that I (the attacker) control, but you don't know that. There's many other types of things you can do with the same restrictions. It's not enough to block scripts and plugins, you also have to prevent the attacker from simply taking over the page with their own content by layering it on top of the Z-order.