I'd argue that any equality comparison of floating-point numbers is asking for trouble, unless you're specifically working with small dyadic fractions (using exact comparison) or testing a purely heuristic 'closeness' condition (using fuzzy comparison).

Of course, inequalities show up in a lot more places, but are similarly fraught with difficulty, since mathematical statements may fail to translate to floating-point inequalities. E.g., in computational geometry, people have written entire papers about optimizing correct orientation predicates [0], since the naive method can easily break at small angles. This sort of thing is what often shows up as tiny seams in 3D video-game geometry.

[0] https://www.cs.cmu.edu/~quake/robust.html

My preferred way to compare floats as being interchangeably equivalent in unit tests is

    bool equiv(float x, float y) {
        return (x <= y && y <= x)
            || (x != x && y != y);
    }

This handles things like ±0 and NaNs (while NaNs can't be IEEE-754-equal per se, they're almost always interchangeable), and convinces -Wfloat-equal you kinda know what you're doing. Also everything visually lines up real neat and tidy, which I find makes it easy to remember.

Outside unit tests... I haven't really encountered many places where float equality is actually what I want to test. It's usually some < or <= condition instead.

I have built a production Javascript library with decent amounts of users that incorporates the following hack to deal with float error (avert your eyes if you're sensitive):

  // 1.2 - 1.0 === 0.19999999999999996
  // fixFloatError(1.2 - 1.0) === 0.2
  var fixFloatError = function (n) {
    return parseFloat(n.toPrecision(12));
  };

It felt correct at the time, but after reading the article, I cringe at how fundamentally broken it is. I got away with it because the library is used to convert betting odds, which are mostly small floating point numbers, so the error is often < 10^-12.