***A new and mostly rewritten version of the original answer which was flawed.** See edit history if interested.*

As any operation making `$MaxNumber` higher (more precisely: higher enough for its `Precision` to notice) results in an overflow, the `Interval` created here has the form

    Interval[{$MaxNumber - something small, Overflow[]}]

The "something small" is approximately `$MaxNumber / 10^$MachinePrecision`. Now it holds that

    0 < Underflow[] < $MinNumber <= anything positive finite <= $MaxNumber < Overflow[] < ∞,

so it would make sense to accept `Overflow[]` for a bound of an interval, at least an open one. As the comments to the original version of this answer show, since there are only unions and intersections in Mathematica's interval arithmetic, even that works in the presence of `Overflow[]`. Of course, some problems will arise with a symbol which effectively represents an out of bounds error, like comparison with itself, but by any means `$MaxNumber` should be a member of the above interval.

I have done a bit of hacking on `DumpSave`s and discovered the following: Mathematica sorts `Intervals` into those that have numerical inputs and those that don't. I would call the latter "incomplete" because this category includes not only `Interval`s with unassigned symbols appearing in the bounds but also those with `Slot`s and `Blank`s. Any incomplete `Interval` automatically returns `False` on `IntervalMemberQ`: try

    (* This gets only evaluated after substitution *)
    f[a_, b_, c_] := IntervalMemberQ[Interval[{a, b}], c];
    f[1, 3, 2] (* True *)

    (* This is evaluated immediately with the incomplete Interval *)
    g[a_, b_, c_] = IntervalMemberQ[Interval[{a, b}], c];
    g[1, 3, 2] (* False *)

or even

    f = IntervalMemberQ[Interval[{#1, #2}], #3] &;
    f[1, 3, 2] (* True *)

    g = Evaluate[IntervalMemberQ[Interval[{#1, #2}], #3]] &;
    g[1, 3, 2] (* False *)

My speculation is that this has to do with optimization: with a numeric `Interval`, all the bounds are compared, sorted along the real line and merged as appropriate as shown by the example

    Interval[{-1, √2}, {0, π}, {7, 8}, {-5, -4}]

    (* Interval[{-5, -4}, {-1, π}, {7, 8}] *)

This can't be done with incomplete intervals. It might be an "expensive" operation so it's good to do it once the interval becomes complete, and if two of these are intersected, unified, or compared, take this condition for granted.

Now what happens in the original examples is that the "incomplete" bit gets set when `Overflow[]` is manually provided as a bound to the `Interval` (even though `Overflow[]` is even explicitly recognized as numeric by `NumericQ` and compares with other numbers well). Somehow the `Interval` produced by `Interval@$MaxNumber` is still marked as numerical, though, and this is preserved under interval operations. This explains the situations with `Uncompress@Compress@` and `Identity/@` applied on the pre-made `Interval` since these force reevaluation of its parts.

In pattern and slot substitutions, a new object is formed so the incomplete bit is reexamined (and the optimizations done, if complete). But as long as the object stays unchanged there is no reason to touch this metainformation. Importantly, *this flag is not a part of the expression tree displayed to the user and is ignored in comparisons*. So if two objects only differ in this (due to an incoherent assignment at one or the other's creation) they look identical and are even considered equal in `===` and similar commands. It is enough difference, however, to prevent `Share` from merging them.

Of course, there are many good points supporting Mathematica's decision not to allow `Overflow[]` as a bound for `Interval` – if it was a design choice in the first place, that is. But one way or the other, this behaviour should be consistent. I agree the inconsistency is a bug, most likely originating in `Interval`.