As any operation making $MaxNumber higher results in an overflow, the Interval created here has the form
Interval[{$MaxNumber - something small, Overflow[]}] The "something small" is approximately $MaxNumber / 10^$MachinePrecision. Firstly, Overflow[] denotes an error, not a bound. If you wanted an interval that stretches from a certain number onwards, you would use Infinity instead.
In this sense it is perfectly legitimate that the operation results in False just like IntervalMemberQ with undefined symbols for example. {a, Overflow[]} does not denote a valid interval so nothing lies within that by definition. You don't need $MaxNumber and the further tricks to confirm that even better-behaved inputs like
IntervalMemberQ[Interval[{2, Overflow[]}], 3] result in False (even though 2 < 3 < Overflow[] gives True: this underlines that IntervalMemberQ has its own logic that must work well with unions, it's not a shorthand for a chained inequality).
So the real question is why the uncompressed formula gives True rather than why in the other cases you get False. I think the answer to this is that Mathematica is giving you a favour by determining the obvious membership of a number within its own neighbourhood prior to evaluating the bounds proper (there may be a quick check for similar basic situations among internal DownValues of IntervalMemberQ). Then, if you force it evaluate them (which both Uncompress@*Compress and Identity/@ done on the Interval part alone do), the overflow situation sets in and results in all further membership queries to evaluate to False.
As a side note, you are usually warned when Overflow[] appears. The corresponding warning indeed appears when you try the same with $MinNumber:
Interval@$MinNumber General::unfl: Underflow occurred in computation. >>
I would say it is a minor glitch that this occurrence of Overflow[] is not reported properly.