This. A thousand times this. Embrace the unix philosophy of small tools and npm scripts and watch your baroque frontend build process with all its plugin dependencies reduce to amazing simplicity. Here's another good write up with some significantly more useful examples:
Unfortunately it embraces it so much that there are several different variations of connecting the parts together, and even then some important tools don't play very nicely with the rest of the Gulp framework.
Consequently, it takes several lines of awkward boilerplate just to run a simple Browserify job that is a one-liner at the CLI. I've also seen Gulp adapters for popular tools, such as ESLint, that break suddenly when something apparently unrelated in the NPM set-up is updated, even though ESLint itself also still runs just fine with a one-liner at the CLI.
In fact, those were the two examples I used when I put my foot down over build tools on one project I work on a little while back. Within 20 minutes we'd replaced well over 100 lines of Gulp code with about 10 one-liner CLI jobs that did all of the same things. The new version has the added advantages of actually working, which the Gulp-based code used to but didn't any more, and of requiring a total of 0 changes since then to remain working, other than when the tools themselves changed their interfaces.
For every small tool you want to use in Gulp you either have to write your own Gulp task in JS, or add a plugin wrapper to the tool as an additional dependency to your project. Doesn't seem ideal. Just by switching to npm scripts you could probably reduce by at least 50% the number of 3rd party dependencies in your build.
Also streaming stuff around inside a Gulp process is good in terms of speed, but imo quite complicated conceptually, and doesn't match the simplicity of piping stdout between one-liner CLI commands.