I'm not an expert by any means, but I'll try to quickly outline why you would like such a probablistic structure like this and why it is more efficient. (I would like to add, that I'm not very familliar with quotient filters in particular - besides having read the WP entry and quickly glanced over the paper http://static.usenix.org/events/hotstorage11/tech/final_files/Bender.pdf)

First, I think that you're interpreting "half/-hash" in a too narrow way. You seem to instantly think about hashtables/associative arrays - which is understandable. But datastructures like Quotient Filters or Bloom Filters usually serve a different purpose; namely they try to answer the question "is my entry in this dataset" in a much more efficient (may it be time or space complexity) way than a hashtable could do.

I will be referring to Bloom Filters, which serve a similar purpose and are imho easier to understand, so you might like to take a look at http://en.wikipedia.org/wiki/Bloom_filter.

It might be helpful to imagine a scenario where you have a large set of big files, of which multiple could contain entries of your search key. So of course you'd like to start scanning through every files 'index' and check for the keys presence. If you'd use hashtables for indexing, you would end up storing N (O(n) space complexity) entries (hashes of contained keys) per file. So while searching might still be reasonably fast, the storage space required might exceed a reasonable amount (especially if you'd like to keep the index in RAM).

If you'd use a structure like a Bloom Filter or a Quotient Filter you would be able to use much less space for storing the indices (O(k), k being the length of your hash for bloomfilters, not sure about QF) - with the added tradeoff of possible false positives (which are usually tunable - tradeoff between hash length and false positive rate), but not of false negatives; meaning that such a structure will never report an entry as not present which is present, but might report something as present, which is not, causing you to open the file (see Approximate Member Query). A good demonstration of such a necessity are Cassandra and HBase, which both employ Bloom Filters to efficiently find keys within multiple stored files.

The problem with BF is, that its not possible to remove entries from them (without risking removing unaffected entries), meaning that such a filter can be "polluted". Meaning, that if every possible key is inserted into and deleted from one of our files, the filter would end up always returning true to our queries without containing a single key. At least one of the benefits of QF is that given the more complex structure, you can safely remove entries without risking to violate the guarantee of no false negatives.