I like to use markdown notation in my subversion commit messages, planning to one day create a "log" function that will output the commit messages in a HTML page, not unlike Trac's "history" view. (If Trac doesn't have a markdown plugin by then for exactly that purpose.)
Can anybody think of any reasons against this?
The only thing special about this that comes to mind is the use of backticks but they should be escaped like anything else, so that shouldn't be a problem.
I use trac, which uses Wiki markup for everything (I just checked and it is also used on commit logs). I mainly use * or - for lists, and trac show them correctly.
On next commit I'll see if it accepts backticks (or {{{ and }}}, which is also accepted by Wiki markup), but it most likely will.
I don't see a reason why you shouldn't use Markdown on your own logs, and may be create a small plugin for your Project management and bug/issue tracking system.
Can anybody think of any reasons against this?
Yes: commits should be plain, unadorned text to encourage minimal commit messages. If you need that sort of formatting, your commit messages are not clearly explaining the purpose of the message. In general, commit messages should be short, succinct descriptions of the changes, no more than two or three sentences. If more detail or context is needed, they can reference external issues (e.g. "Fixes issue #184 graphical bug").
If this is not merely a personal preference and your commits actually do require a significant amount of detail and formatting to explain, then they are probably too big and should be broken up into smaller, more easily digested chunks.