It's sort of broken, sort of pointless, and sort of being held wrong.
There's no special syntax inside the map transform input expression to refer to the incoming property. This appears to be by design, or at least it's been that way from the beginning, and I can see some defense of it. Remember that what you're doing here is returning an expression that itself defines a numeric value case to use in the map filter -- a fairly contrived scenario; typically the conditions for a map transform would not be dynamic, or if they were, would not be dynamic on the value passed in to the transform.
So in this case {value} is being treated as tag lookup, which basically guarantees it fails unless you have a literal tag named value at the root.
But even if that worked, in your first example you're using two expressions that return boolean conditions - true or false. Those are not numbers, so (even if the lookup worked the way you want it to) they're stored in an internal map as true and false.
Then your property is evaluated against those values. Because the stored key was not numeric, the input number is treated as an exact reference - and 123 (or whatever number) is not exactly the same as true or false from Java's perspective. Thus you hit the fallback case.
To prove that it's all "working", by some definition of working:
If I have a tag value with a value >= 50, the first case in my map transform is true -> red.
And I make my input property a literal boolean (not a 1/0!):
I get the output color I'm expecting:
