A Bloom filter with an error rate of 1/10^8 requires about 40 bits per item stored. That's about 5 bytes per element, which is comparable in magnitude to just storing the dictionary as a single string. It does also require quite a lot of independent hashes, but it's still going to be cheaper to do the lookups than a linear search through a string.
(On the other hand, it might not compare so favourably with "binary search until we've got it down to a smallish substring, then simple linear search".)
The number of bits you need in a bloom filter varies as a function of the number of items you have (in addition to the desired error rate). Assuming a 100 items, a 1e-8 error rate only requires 480 bytes (= ~5 bytes per item).
You also don't need to do a lot of independent hashes. You can just take a linear combination of the results of two hashes and get basically no performance degradation (see: http://www.eecs.harvard.edu/~kirsch/pubs/bbbf/esa06.pdf).
Also, you probably don't actually need a 1e-8 false positive rate, since you're going to fall back to a canonical (but slow) lookup table for positives in most use cases. Bloom filters are most useful when your real dictionary is slow and you're expecting a lot of 'no match' results.
> Also, you probably don't actually need a 1e-8 false positive rate
Absolutely not. I just wanted to demonstrate that even if you do want a very low false-positive rate from your filter you don't need a very large data structure, contrary to jeresig's fears. Bloom filters are very, very space-efficient.
(On the other hand, it might not compare so favourably with "binary search until we've got it down to a smallish substring, then simple linear search".)