When your method can be synchronous (simple data transformation), then use synchronous code in that method.
However if the method can be synchronous sometimes, and asynchronous sometimes (multiple code paths based on internal or external state), it should be asynchronous always. Otherwise, you may encounter unexpected subtle discrepancies in how your code behaves in complex scenarios, so it's best to avoid mixing the two attitudes.
[edit] As noted in comment, when your method is synchronous for now, but you strongly believe it might need to do async work at one point in the future, you might want to use promises from the beginning to avoid costly refactoring.
In general, your API should be consistent, so it's best to either use promises everywhere, or callbacks everywhere. This will make it easier to reason about the code.
If you are writing ultra high performance code and/or need low memory footprint, you may consider not using promises but callbacks, or using a promise library with a focus on performance, like bluebird, instead of the native Promise implementation / general use case polyfill.
[edit] Anyway, new additions to the web platform, like global fetch function, return a Promise, and it seems that in the upcoming future more and more browser built-ins will be operating on promises. So if you're willing to write modern code, you're not going to escape promises.
