Wikitext is a monstrous and ferocious beast. Born from a small set of markup choices for text formatting, it has since grown to a plethora of markup and functions. It’s gotten to the point where people are afraid to edit, due to the nearly insurmountable hurdle of learning the syntax.
The problem with wikitext isn’t in its design itself, it comes when people try to make wikitext do things it was never intended to do. Years ago, people realized that they could make a conditional template. The English Wikipedia produced a template called {{qif}} that quickly became used across the entire wiki. This was terribly inefficient, so ParserFunctions was born to solve this problem, and parser functions in general were born.
At some point, somebody wrote an extension to handle string manipulation called StringFunctions. Ever since then, enwiki has been practically begging to get it enabled (see bug 6455). This request has been repeatedly denied by the WMF sysadmins, in an effort to keep wikitext from becoming even more insane. Similar to {{qif}}, a series of workarounds have been written.
In our future ideal universe, we’d like to have some sort of meta programming language for templates. Various ideas have been tossed around, including a subset of PHP, Javascript or Lua. Any of these solutions each have their own set of benefits and drawbacks, and none of them are anywhere close to being enabled. And so the debate continues, often, as to what we should do with wikitext.
I remain convinced that wikitext itself is not inherently bad, and does not need fixing. The basic formatting markup and template inclusion is not horrible. It’s when people try to butcher wikitext to make it do things it was never designed to do that we get nasty results. Adding ParserFunctions didn’t ruin wikitext, ParserFunctions was designed so Wikipedia wouldn’t kill itself trying to implement their own {{#if}} function. I would argue that the English Wikipedia’s desire for programmatic templates is what made the language is what made this mess.