In principle, I agree; for pragmatic reasons, I believe efforts like WADL make sense, if only to have an answer to one of the most obvious questions for new REST converts :-)
+1 to that.
Take a gander at the spec. I tear up just looking at it. It is beautiful compared to WSDL - just beautiful.
I think that the risk with any service description language is that people take it too far and become overly dependent on it. Generating code from them tends to do this. But then again, code gen can be helpful. You just have to know when you have taken something too far and not be afraid to press the eject button to dumb it back down.
I think that REST client developers at the very least will want schema definitions of what to expect in request/response payloads. IMHO WADL does a good job of not taking things too far. As I said, compared to WSDL it is a thing of beauty. It is so simple when the only option is HTTP (i.e., compared to the absolute insanity of protocol agnosticism).
If you aren't going to use WADL, you are going to have to document the service in prose or some such. WADL at the very least seems to be a really concise way to document things.
Update Somebody should give Mark Baker a trophy or something. I still will take WADL any day over WSDL, but Mark is probably right. Still, I'll take baby steps if that is what it takes.
Update 07-JUN-2007 I have been convinced that a service definition language is not good idea right now.