Having unique passwords entered to every site IS safer than giving each site the same password, for exactly the independent-compromise reason you suggested.
If an attacker has the hash, and knows that it was generated with PwdHash and knows the domain that it was generated for, how feasible would it be for them to determine the original password from that?
Well, let's do some investigation and some math! PwdHash appears to be using effectively GoofyStuff(Base64(HMAC-MD5())), so we're at the usual MD5(MD5()) guessing game speeds. Per oclHashcat, "PC5 (8x AMD R9 290Xstock core clock)" can crack ~81 Billion MD5's per second, so ~40 billion tries as PwdHash per second, which gives us the more practical 1E17 (somewhat over 2^56) tries per 30 days.
I base the above on this snippet from a quick glance at the PwdHash page source:
var hash = b64_hmac_md5(password, realm);
This is in the range of an exhaustive keyspace search of 62^9 to 62^10 in those 30 days, where 62 is the keyspace of upper case, lower case, and numbers (or upper case, lower case, and the symbols above numbers, whichever you like), and 9 or 10 is the length.
Thus, a fully random upper case, lower case, numeric password encoded with HMAC-MD5 will be found in less than about 30 days (unless you and the attacker are using different character sets (i.e. Cryllic vs. English)). You'll need something with a larger total keyspace than this for your master password, and that's if it's a truly random password!
You don't even want to think about what a rules based dictionary attack can come up with at this speed, if your password is not, in fact, fully random. My most comprehensive wordlist set is over 40GB of unique passwords; if we assume an average word length of 9 plus a LF separator, that's 4E9 words, meaning that if an attacker with that PC spent 30 days on your password, they'd be able to try roughly 2.5E7, i.e. 25 million different variations (rules) for each password.
Note that this wordlist is too slow and cumbersome to bother with... unless the target can be attacked at insane speeds, like a single HMAC-MD5 can.
If you do use PwdHash with a master password, have a really, really good one - 15 character or better, cryptographically random, with a large character set (upper, lower, number, symbols above numbers, symbols not above numbers).
You should think about how you're going to change your master password after it leaks; perhaps you're up late and are trying to hurry and you type the master password into a web site directly instead of into PwdHash, just by habit, caffeine deprivation, hurry, and carelessness. Now you need to change it!
Personally, I like offline password storage like KeePass, but I'd much rather use even basic OpenSSL than PwdHash - AS PATHETICALLY INSUFFICIENT AS IT IS, I'll put HMAC-SHA-512 up against HMAC-MD5 any day of the week.
echo example.com2014 | openssl dgst -sha512 -hmac MyPassword -binary | openssl enc -base64
As always, you're better off using something truly random and storing it, or, if you insist on a deterministic generation routine, something really, really slow - particularly since this is just for you, so PBKDF2/BCrypt/Scrypt with enough iterations/work factor that takes even a second or two or five on your machine would be just fine, and would slow down an attacker to a crawl.
Shameless plug: I'm working on collecting a variety of PBKDF2 (and hopefully later BCrypt and Scrypt) code examples at my Anti-weakpasswords github page, some of which compile so you can run them at the command line of Windows or Linux, and use them exactly the way you're using PwdHash now, but with a higher iteration count than almost any website could use, if you're willing to wait a couple seconds. As of today, there's only a Python version that Mitsuhiko wrote and Warner fixed for high iteration counts, not yet updated with better hashes, but that'll improve.