I can see how this could be extremely useful, but it does strike me as yet another source for unique bugs in your JS-manipulating-DOM code, and it's potentially even harder to find out why they're happening.
The user agent it reports as is irrelevant - it's not a full http client. You can use other ruby tools to fetch a page if you want, and then feed harmony the document.
As others pointed out, testing is probably the main use case, but it offers other obvious possibilities; for instance, talkerapp.com needed a way to easily validate js syntax for their plugins.
As to the libraries to make things cross-browser compatible, knowing which browser it tries to emulate would be essential to knowing which lines of code would be executed through this tool. If you can't test the IE-specific code, what's the use if you're developing for IE?
I'll continue to periodically run my tests inside a "real" browser, but I think this sort of headless testing is a real win.
[Disclaimer: I wrote Johnson, so I'm not exactly a disinterested bystander. Edited for repetition.]
(FWIW, a coworker and I did this a few years ago with Rhino and a custom-hacked mock DOM. Doing it with a real DOM, like what an XML parser gives you for your actual page, is much better! Hopefully that's what this library allows.)
It's more common than you think.