Yes! A thousand times yes!
Being free-form is also extremely important. I think that the best way to add another "stuff specific to some particular use-case" is just to add additional layers of UI over current form.
Look at how HTML mail is implemented - it's just using underlying text protocol. Ditto for images and other attachments.
I don't see any reason for people not to agree on Markdown formatting, folding Org-mode style headings, rendering [ ] as checkbox that will send a special "I'm ticked" e-mail as a reply when clicked (didn't GitHub start to do something similar with checkhoxes in readme files recently?), etc. Just keep the underlying format simple and gracefully degrading to plain-text for clients who don't support your new feature.
Quite a few of these email replacement services seem to add a bunch of stuff specific to some particular use-case. It might make it nicer for that particular use-case, but as soon as you need to do something outside of what's anticipated, it grinds to a halt. That means that any organization that uses something like that ends up using 3 or 4 of them, in addition to email. At that point, it's easier to just use email for everything.