The idea is to improve code composition by creating synchronicity. With Promises, you generally have to return the promise and then attach a then method to do something which is contagious and creates tons of dependencies on promises.
What you describe is the "old" way to use promises.
Instead, you can yield promises inside generator functions, or better yet use async/await with a transpiler. Both methods give you nice sync-looking code.
I guess what you're trying to say is that once you adopt Promises a large portion of your code will have to be tailored to use it.
To which I respond: .. yes, so what? It's better than callbacks. And it's better than some "magic fairydust" that doesn't make it explicit that you're doing something async.
Promises are better than callbacks but far worse (in terms of complexity they create) that synchronous code. This might be fairy dust but it crushes promises for reducing developer cognitive load. Having said that I agree with the person who commented that async/await is a better way to go (although sadly not really an option in CS yet).
CoffeeScript! :-) One of those neat compiles-to-JS languages!
Edit: And the "problem" with async/await and CoffeeScript is that the former is currently available in various JS transpilers but you can't use one of those and CoffeeScript at the same time.
> once you adopt Promises a large portion of your code will have to be tailored to use it.
This isn't a necessity, since you can create a function which both returns a Promise and accepts a callback. Most Promise libraries make this easy to support, which makes it easy to introduce Promises into projects that already use callbacks, and vice-versa.
