To be clear, ordinary user of the dialog tools most certainly does *not* involve knowing javascript or Lua or html. The whole point is to arrange that an ordinary wiki users can do wonderful things using *only wiki markup*. (The hypothetical example of a url there is, btw, entirely wrong; but one wouldn't write any sort of url anyway.)
The syntax for specifying a typical button would be more like {{dialog/view|page::Name of page}}, but most people wouldn't even have to figure that much out for themselves --- they would copy-and-modify somebody else's markup they'd found somewhere that did something similar to what they wanted, and they'd use common sense for how to modify it. That's part of the great strength of wiki markup: you do simple things, and while doing them you see other, slightly more advanced things that others have done, so later on when you find you want some of those slightly more advanced things, you've seen them before and know where to look for examples.
Yes, there is in fact a lisp interpreter written in Lua. It makes up for some other weaknesses of templates. I expect most users not to have to touch that most of the time, and when they do they'll usually be able to just copy others' markup and make slight, obvious modifications. It's so vastly handy that I've used it (you've reminded me) in some of the dialog templates, just because it's so much easier to do things with it. I created it because it was obvious I'd need a powerful succinct way, without the cumbersome notational overhead of templates or Lua (or JavaScript, perish the thought), to specify transformations of the raw content of a wiki page; and the one place thus far where I use it intensively is for just such an application (removing from a wiki page all template calls of one kind, and modifying all those of another kind). I expect to be able to readily build tools, using dialogs and that lisp interpreter, to do things of the same general order as HotCat (only more sophisticated), and given the contrast between a few lines of Lisp and the JavaScript source code for HotCat, I think I'm quite justified in considering it an improvement... if it proves out. (There is some question whether this technique as currently implemented will really scale to manipulating the whole content of large wiki pages, due to practical limitations that may be imposed on the dialog tools by... the template-handling of the wiki software; but we'll see at what scale that becomes a problem, an what might be done under the hood to move the threshold when encountered.)
I do agree that templates are rather broken, although frankly the Foundation could --- with some deep insight --- have done things that would have improved them. The current plethora of magic words is a mess, partly because the template call-syntax is heavy and pure template/magic-word usage keeps sending things back to typeless text; both of which problems are not shared by my embedded lisp interpreter, with it's very-low-overhead call syntax and its simple, minimal, but highly useful dynamic type system.