This is a fascinating question. The other answers here are all speculative, and in some cases flat-out incorrect. Instead of writing my opinion here, I actually did some research and found original sources that discuss why delete and put are not part of the HTML5 form standard.
As it turns out, these methods were included in several, early HTML5 drafts (!), but were later removed in the subsequent drafts. Mozilla had actually implemented this in a Firefox beta, too.
What was the rationale for removing these methods from the draft? The W3C discussed this topic in bug report 10671. Mike Amundsen argued in favor of this support:
Executing PUT and DELETE to modify resources on the origin server is straight-forward for modern Web browsers using the XmlHttpRequest object. For unscripted browser interactions this not so simple. [...]
This pattern is required so often that several commonly-used Web frameworks/libraries have created a "built-in" work-around. [...]
- Using POST as a tunnel instead of using PUT/DELETE can lead to caching mis-matches (e.g. POST responses are cachable, PUT responses are not(6), DELETE responses are not(7))
- Using a non-idempotent method (POST) to perform an idempotent operation (PUT/DELETE) complicates recovery due to network failures (e.g. "Is is safe to repeat this action?").
It's worth reading his entire post.
Tom Wardrop also makes an interesting point (href):
HTML is inextricably bound to HTTP. HTML is the human interface of HTTP. It's therefore automatically questionable why HTML does not support all relevant methods in the HTTP specification. Why can machines PUT and DELETE resources, but humans cannot? [...]
It's contradictory that while HTML goes to great lengths to ensure semantic markup, it has to date made no such effort to ensure semantic HTTP requests.
The bug was eventually closed as Won't Fix by Ian Hickson, with the following rationale (href):
PUT as a form method makes no sense, you wouldn't want to PUT a form payload. DELETE only makes sense if there is no payload, so it doesn't make much sense with forms either.
However, that's not the end of the story! The issue was closed in the W3C bug tracker and escalated to the HTML Working Group issue tracker:
At this point, it seems that the main reason why there is no support for these methods is simply that nobody has taken the time to write a comprehensive specification for it.