It allows web APIs built-in to the browser to return a promise, e.g. audioContext.decodeAudioData(data).then(...). If you just used a library, the browser wouldn't know how to wrap the returned value in a promise. It also guarantees interoperability between all APIs using promises, avoiding any incompatibility between different libraries.

Paving the cowpaths. Promises were already standardized before ES2015 arrived, but now you can just write libraries using promises without having to rely on the developer providing their promise implementation of choice. This also prevents scenarios where you might end up with N different promise implementations because you're using N libraries, each depending on a different promise module (e.g. bluebird, Q, jQuery.Deferred, AngularJS $q, etc) all of which are slightly different.

This also means more feature-rich implementations can just extend the native promises instead of implementing everything from scratch, though for me this pretty much spells the end of third-party promise implementations.

In other words, they've been added for the same reason as the various new helper methods: not because they add new functionality, but because they provide a reliable well-defined and consistent solution to a very common problem.