I would like to caution against expansion of core APIs in cases where we already have a way to do it.  In almost every corner, Python's APIs are growing, resulting in the language becoming massive, where very few people on the planet can claim to know what is in it and it is becoming much harder to teach as it gets bigger.

Also, we should place very little value on anecdotal evidence from one core developer who says he once wrote a single line of code that would have benefitted from a single part of the proposed changes.  In general, core devs tend to write much more generic code than end users, so our needs are often atypical and do not reflect user needs (in this case, no non-core-dev numeric user has ever requested this behavior or had a real use case that couldn't be met by the existing APIs).  The bar for new APIs is much higher than "I wrote a line of code once".  

We should be looking for APIs additions that significantly reduce complexity or solve problems that can't easily be met with existing APIs.  Minor expansions create long term maintenance burdens, increase the size of docs making them less usable, cause other implementations to have to follow suit, cause subclassers and users of the numeric module to have to implement additional methods, and make Python more difficult to learn.  There is a reason that the zen expresses a preference for only one way to do it.

Replicating parts the decimal API should always be suspect as well.  In general, that module is much more difficult to use and learn than regular floats.  Many parts of the API are simply worthless and are there only because they were part of the spec.  We have no evidence that any of these proposed methods are actually being used and are of real benefit to real users.

Also, remember that Decimal is not registered as a Real for a reason.  Guido does not consider them to be interoperable with binary floats.