It's a completely illogical use of CASE SELECT, as it turns it into
nothing more than an IF/THEN/ELSE.

Now, the only possible justification I could see is if you had
something like this, where you wanted the same branch in your code
from more than one expression (i.e., two different expression
results would branch into the same subroutine):

CASE SELECT TRUE
 CASE <expression1>, <expression2>
   ...
 CASE <expression3>, <expression4>
   ...
 CASE ELSE
   ...
END SELECT

But, what is more difficult about:

IF <expression1> OR <expression2> THEN
  ...
ELSEIF <expression3> OR <expression4> THEN
  ...
ELSE
  ...
END IF

You type a comma instead of OR.

That's the only difference I can see.

The efficiency of CASE SELECT is supposed to come in the fact that
you evaluate an expression once, then compare the result to a number
of values, each of which branches in a different direction.
Evaluating TRUE once, then comparing it to a bunch of
non-independent expressions seems to me to turn the entire logic of
CASE SELECT inside-out. My suspicion is that CASE SELECT TRUE with
conditions in the cases means that it can't compile as efficiently,
and could mean that it is slower.

But I don't know that for a fact.

I do know that if your condition is there once, and the cases only
have literal values to compare to, those values must surely be
compiled as literal values in the VBA p-code. That's surely the kind
of thing that's highly optimized in VBA.

But that efficiency wouldn't really matter except if you were using
this approach in some function or subroutine that was called in a
loop or in a query result (so that it executed for each row, for
instance).

I just think that it's better to avoid that kind of upside-down CASE
SELECT than it is to try to figure out which circumstances in which
it will be OK and which it won't. I especially think that's the case
when there's a perfectly good and easy-to-write and -understand
alternative branching structure available.