I often write my code pessimally in this regard so have a note in the back of my mind to someday use these in a few hot paths.

When I say “pessimally” I mean I usually check the unlikely cases right away and then put the normal case last:

    Blah foo (something& arg) {
    
      if (is_invalid  (arg)) return blah(0);
      if (is_inactive (arg)) return blah(1);
    
    // ok do all the normal stuff
    }

It makes the code clearer but slightly slower. I could always write a conditional for the hot path up front, but code is for human readers, right?

So when people say “this clutters the code” they are right, but most of the time you just don’t worry about it — it need only clutter a few functions in your hot loops, where you’re willing to rewrite it anyway regardless of how ugly it gets.

It’s like looking at the standard library source: super cluttered, but it has to handle all sorts of weird corner cases and is called a lot. Normal code can ignore all that in more than 99.99% of the cases.