Rationale of IEEE754 direct rounding behavior near infinity [closed]

Question

A preface: it's well known that IEEE754 defines five rounding modes (in 2008 edition terms, with my abbreviations):

1. rounding to nearest, ties to even (RNE) - the default mode for binary arithmetic;
2. rounding to nearest, ties away (RNA) - required only for decimal arithmetic, rarely supported for binary one;
3. rounding toward zero (RZ);
4. rounding toward positive (RPI);
5. rounding toward negative (RMI).

In very most cases, RNE is used; it's required by default for binary calculations and many people are ignorant of other modes, or they are unavailable (e.g. Java and Python standard libraries don't provide rounding mode change).

In RNE and RNA, there is an explicit requirement to generate Infinity in cases a result is sufficiently larger than the largest presented finite number. Literally, citing IEEE754 draft with TeXization, "an infinitely precise result with magnitude at least b^emax * (b – 0.5 * b ^ (1−p)) shall round to ∞ with no change in sign"; technically, this is identical to another description of the same approach: a single value, which would be next representable in case of infinite exponent range (2^128 for "single" floating, 2^1024 for "double" one), is added to the supported set during exact calculation, is possible as target point for rounding, and then converted to infinity when packed to the final operator result. (UPD: variant from @gnasher729: limited mantissa precision but unlimited exponent, and then fitting into exponent limit, is also suitable and even easier to describe.) This corresponds well to the role of "infinity" in floating point arithmetic - to mark a past range overflow, despite formally the result is closer to any finite number than to the real infinity.

Unlike "to nearest" rounding modes, "direct" ones dictate a principally another approach; for RZ and RMI, +∞ is never generated. The maximal finite number in "double" (DBL_MAX) is approximately 1.8e308. If one multiplies 1e308 by 1e308, the result is +∞ for RNE, RNA and RPI, but DBL_MAX for RZ and RMI. For multiplying 1e308 by -1e308, the result is -∞ for RNE, RNA and RMI, but -DBL_MAX for RZ and RPI. This "rounding" is principally a catastrophic, I won't be ashamed of this emphasis, accuracy loss - for order of ~308 decimal magnitudes, or 1024 binary ones. (Yes, I see overflow is signaled in such case, at least in my tests, and according to the standard. But it's unclear where exactly the overflow happened, and the bogus finite value can spoil following results.)

So, finally, the question: why the direct rounding modes don't round to infinity if a operator result is far enough from the represented value range, as "to nearest" modes do? Is this a legacy issue, or an intentional approach? In the latter case, what was the goal?