I believe that this was a deliberate design decision, though now that I look it seems it's not well documented.  That should probably be fixed, so I see this as a documentation issue.

More details:

The specification on which the decimal module is based requires that there be a 'remainder' operation with the semantics of Decimal's '%' operation (i.e., the result of x % y has the sign of x).  However, the specification doesn't say anything about how the prescribed operations should map to language constructs.

So the choice was between (1) leaving '%' for Decimal objects unimplemented, and providing a separate 'remainder' method, or (2) mapping '%' to Decimal's remainder operation, and accepting the slight mismatch between the '%' semantics for float and Decimal.

Perhaps the wrong choice was made.  But it's there now, and to me it's not so obviously wrong that it's worth the upheaval of deprecating '%' for Decimal objects.

Of course there's a third choice, which is to implement the float % semantics for the Decimal type;  however, this is outside the scope of the specification---none of the specified operations matches this behaviour, and I'd oppose the addition of such an operation to the Decimal module.  There's a strong sense in which Decimal's % is a more natural operation for floating-point types than float's %.  (For one thing, it's exact in many circumstances, while float's % suffers from surprising results with negative operands.)

Reclassifying as a documentation issue.