Promises are superior in general, I guess that has been discussed already[1], many times. Promises may indeed offer just an insignificant benefit sometimes (you can even call it just a different style), for example when you are first writing a monolithic prototype. In this worst case, you would simply make a giant chain of ".then" methods, any your gain is you can get creative with the error handling if you want. However, the greatest benefit revels itself later: The composability that comes with them will help you immensely when refactoring.
[1]: One example: http://softwareengineering.stackexchange.com/a/302456/9451 Another: http://blog.parse.com/learn/engineering/whats-so-great-about...
Performance may be a tradeoff for the current engines, but I'm optimistic that it will be optimized away as it doesn't add too much semantics over the callbacks. Maybe error handling is tricky.
I would say they are superior to callbacks as object-oriented code is to procedural code - that also has some performance cost in many engines.
But, you are saying tradeoffs - plural. I, as an experienced web developer, am sincerely curious what any other can be?
That is not a universally-accepted statement either.
I'm not interested in taking sides here, only pointing out that there are a wider variety of extant opinions than you seem to realize.
The sounds like a limitation of promisify, not inherently of callbacks. There are many situations and styles where callbacks are perfectly adequate, and promises offer no benefit, so referring to it as the "old callback style" may be a bit premature.