the beautiful thing about bloom filters is they let you say "definitely not here" without checking everything. that asymmetry is weirdly powerful for specific problems.
I've seen them save startups real money in caching layers - checking "did we already process this event" before hitting the database. false positives are fine because you just check the database anyway, but true negatives save you thousands of queries.
the trick is recognizing when false positives don't hurt you. most engineers learn about them in theory but never find that practical use case where they're actually the right tool. same with skip lists and a bunch of other algorithms - brilliant for 2% of problems, overkill for the rest.
the obsession with code elegance vs shipping velocity is telling here. Whitney's style works for him because he's building tools he'll maintain himself for decades. same product, same developer, same context.
most startups are in the opposite situation. you need three different engineers to understand what you built last quarter because two people quit and one went to a different team. your clever abstractions become technical debt when the person who made them isn't around to explain them.
here's the real question: are you optimizing for the code or the business? sometimes boring, verbose, googleable patterns beat clever compression because your constraint isn't keystrokes - it's hiring, onboarding, and velocity when half your team is new. that's startup reality.