My guess would be that the programmer put them in the URL in order to avoid the problem of someone pressing 'refesh' on the error page generating a re-submission of the form.  Doing this via a redirect to a URL avoids the resubmission problem without needing to get involved in session management (ie: staying RESTful).  However, whatever is passed in the URL should be sanitized before being displayed.  I haven't looked at the source either, so I don't know how complicated it would be to fix this, but if what is normally passed is only text, just escaping it before displaying it should be an almost trivial change.

And yeah, it would be nice to fix 'clear this message' to completely clear the URL, too.

I meant "removing them from the URL". The messages should be written in the HTML directly without changing the URL.

Not sure what "those messages" are that you want to remove altogether, but please notice that "they" probably also include error_message, which is a way to indicating an error to the user. I disagree that these should be considered annoying; they are fairly important indeed.

As to why they are in the URL: I still don't have an answer to that question. Anybody interested should probably investigate the source code, or ask on the roundup tracker.

What's the point of putting those messages in the URL instead of generating them
server-side and put them directly in the HTML?
I would remove them altogether, they are annoying and also dangerous. Moreover I
don't see any advantage in having them in the URL and it looks to me like a
quick hack used to avoid writing a few more lines of code to handle these
messages properly.
I also usually have to copy the URL of the issue I just created/edited, and that
text make it more difficult to copy, because I have to select just the relevant
part. (The "clear this message" doesn't help either because it still leaves some
extra text in the URL.)

... amusingly, the ok_message I got from posting that uses a HTML tag.  A <br>
specifically.

http://psf.upfronthosting.co.za/roundup/meta/issue296?@ok_message=msg%201450%20created%3Cbr%3Eissue%20296%20messages%20edited%20ok&@template=item

Right.

It'd also be worth auditing for any similar vulnerabilities.

So if the ok_message would escape all HTML markup characters, it would not be
vulnerable anymore, right?

If it allows arbitrary HTML is presumably allows javascript as well. 
http://en.wikipedia.org/wiki/Cross-site_scripting#Non-persistent

It could, for instance, be used to steal bugtracker passwords or post spam.

Why is that a vulnerability?

http://bugs.python.org/issue6535?@ok_message=%3Ci%3Ebob%20was%20there%20too%3C/i%3E