Commit 82417ca9b2 includes Decimal's in the numbers tower, but only as an implementation of the abstract numbers.Number.  The mentioned reason is "Decimals are not interoperable with floats" (see comments in the numbers.py as well), i.e. there is no lossless conversion (in general, in both directions).

While this seems to be reasonable, there are arguments against:

1) The numbers module docs doesn't assert there should be a lossless conversion for implementations of same abstract type.  (Perhaps, it should.)  This obviously may be assumed for cases, where does exist an exact representation (integers, rationals and so on) - but not for real numbers (or complex), where representations are inexact (unless we consider some subsets of real numbers, e.g. some real finite extension of rationals - I doubt such class can represent numbers.Real).

(Unfortunately, the Scheme distinction of exact/inexact was lost in PEP 3141.)

2) By same reason, I think, neither binary-based multiprecision arithmetics package can represent numbers.Real: i.e. gmpy2.mpfr, mpmath.mpf and so on.  (In general, there is no lossless conversion float's, in both directions.)

3) That might confuse users (why 10-th base arbitrary precision floating point arithmetic can't represent real numbers?).

4) Last, but not least, even some parts of stdlib uses both types in an interoperable way, e.g. Fraction constructor:
    elif isinstance(numerator, (float, Decimal)):
        # Exact conversion
        self._numerator, self._denominator = numerator.as_integer_ratio()
        return self