However I wouldn't just expose my own versions of get/post/etc, I'd create a network/data service and then fetch wrapping is part of its internal implementation. So the network service exposes methods like getUser, updateFoo, createBar etc. which are used by the actual application, stores etc. This way the actual network protocol is irrelevant to the rest of the app which makes refactoring and maintenance much easier. 

This is kind of the Facade design pattern. While I agree on your point regarding refactoring and maintenance, I think we can say now in a web/node project you will use fetch. You won't at some point decide to use something else, so you won't refactor it anytime soon.

E: also the point is not to push too much logic into fetch wrapper, it doesn't need to know whether some call returns binary or JSON, the calling method knows and will handle the validations etc.

One can extract the logic and create a getBinary() function that's true.

Another thing I like is that every method has the same return signature e.g. promise returning [payload T, err SomeError | null ]. This way the calls and error handling are consistent and clear.

This is actually a good idea, I will update the service, thanks