Agreed, in the code-readability sense it's a little on the strange side, but I wouldn't call it completely nonsense either. My thinking behind the design was that developers are a lot easier to deal with than end-users/laypeople who you might rely on to help debug things. Besides, it's easy enough to write wrapper functions or use DEFINE (in the case of C/C++) to make the code more code-readability-friendly.
Nothing is perfect for everyone, and I think the response is probably the least important aspect of HAPI. The biggest bang for the buck in my mind is self documenting URLs and support for only HTTP-GET verbs. Just my $0.02 :)
It depends on what you want to support. I've done similar as I was working on platforms that didn't actually support POST/PUT/DELETE. However you then have to contend with misbehaving caching too.
So let's not a call it a security issue then. Let's call it an "it's too easy to delete" issue. And if that's the case, then that's what we're going for— easy. Remember, if you were truly protecting something that was secure then you would require a security token parameter— which BTW is something we're planning in the next rev, for people who want to protect their machines.
If I was phishing to get you to click on a link to delete a resource, then I would need to know that token, and if I knew that token, then I could just delete it myself. Note that the HAPI spec discourages the use of cookies (which I agree could allow a phishing attack if you were using cookies as a security mechanism).