Hey Jeff,
Yes, you've got it. when/cancelable is a simple-minded module that has been around for a long time, from well before cancelation was discussed seriously. One major difference is where responsibility for cancelation lies. In when/cancelable, like you said, it's basically a hook for the *producer* to run an extra bit of code just before rejecting a promise. The discussions on promises-aplus are around granting concelation privileges to *consumers*. IOW, it requires a signal from a consumer back to the producer, in contrast to the typical promise signal of fulfillment or rejection from producer to consumer.
The reason when/cancelable is deprecated is that I just haven't seen compelling use cases for it that can't be handled easily in other ways.
As you saw, consumer cancelability is still very much an open discussion. Some people feel like allowing a single consumer to cancel a promise's underlying task (traversing backward in the promise chain to some point) grants too much authority for one consumer to affect other consumers. Bluebird mitigates that somewhat via it's cancelable/uncancelable apis. For simple use cases, it probably works well. IMHO, it still seems easy to make a mistake that may be hard to track down later.
Others feel that cancel should be more like a consumer simply saying that it has lost interest in a promise, kind of an "unthen", like DOM event removeEventListener or somesuch. The underlying task may still be notified of lost interest. It's not clear to me exactly what should happen when all consumers have lost interest. For example, the producer could simple cancel the underlying operation (eg an inflight XHR). But then it's also not clear what should happen if a new consumer appears after that ... should the operation be restarted? etc. etc.
Still others feel that cancelability has no place in promises: since a promise represents a value, it doesn't make sense to cancel a value. They feel there is a distinction to be made between a promise and the task which will produce its value, and that it's the task that needs to be cancelable. Of course, in the current Promises/A+ and ES6 Promise world, there is no first-class Task to cancel. Conceptually, I think the separation makes sense, though.
I hope that helps a bit!