At some point since Python 2.7, the EMin, Emax members got more restrictive bounds. Emin cannot go above 0 and Emax cannot go below 0.

I would argue against this logic:
.prec specifies total precision
.Emin and .Emax effectively limit possible locations of decimal point within the given precision. Since they don't specify / enforce EXACT position of the decimal point, what's the point of limiting them?

Without restrictions, setting Emin = Emax = some positive number effectively restricts number of decimal places to exactly that positive number without a need for separate (and expensive) .quantize() calls.

Removing this restriction provides an option to use decimal as true fixed-point arithmetic.

I would expect this to be a difference between the original pure Python implementation and the current C accelerated implementation.

The constraint is in alignment with the General Decimal Arithmetic Specification that the decimal module aims to implement, which requires that Emin and Emax define a balanced range about zero. (That is, Emin = -Emax +/- 1)

The fact the pure Python implementation didn't enforce that constraint was an implementation detail - other implementations (including the cdecimal module, which was incorporated into the standard library to provide CPython's C accelerated version in Python 3.3) are free to enforce it.