To reiterate the top comment up above, the idea of this tutorial is to explicate everything a front-end dev might need to know. Furthermore, the tutorial is deliberately throwing in wrenches here and there (problems with loaders and such) in order to convey "how might one approach a similar problem".

You're absolutely correct that most of this is, strictly speaking, unnecessary to get a basic React project off the ground. But one idea I don't think gets credit from folks not actively involved with front-end development is that medium-to-large scale front-end developers have very few choices regarding the runtime environment of their code- especially at B2C companies. Your scripts have to eventually be Javascript, and your stylesheets have to eventually be CSS. It's incredibly tedious to write reams of this stuff in a way which works across browsers. Moreover, libraries which abstract across browser differences (like jQuery) need to be transmitted to the client, and eat up runtime.

If you're looking to just hack around with this stuff, try just using one piece at a time. It's relatively easy to just `npm install --save-dev babel-cli` and use it completely independently of Webpack- just letting it happily do its transformation thing.

1. Babel "presets" are basically just individually-packaged sets of syntax transformations that Babel can uses to transpile your code into ES5-compliant Javascript. If you don't give it a preset, Babel will happily transform your code into... exactly the same code. If you give it the ES2015 preset, it will transform ES2015 syntax constructs into equivalent ES5 constructs. If you also add the JSX preset (as is common in React projects), it will convert JSX syntax into the corresponding React function calls. For instance, <span className="hello" /> would be converted into React.createElement("span", { className: "hello" }). Various other presets apply other transformations, but the general idea is to allow developers to begin using language features in their codebase which don't have full support across browsers.

2. The thing with Gulp is that it's a great general-purpose Javascript build system, but its primary use case became transpiling and packaging assets for single-page applications. Integrating these build steps into a pipeline tended to be frustrating- there was a disconnect between what people wanted to do (I just want my assets transpiled, compressed, and bundled, kplzthx) and what they had to implement to do that (writing and wiring up Gulp tasks). Webpack kinda turns that on its head- it implements bundling via its various plugins.

3. Because this tutorial is using a lot of Webpack loaders, and until you kinda grok loaders, it's going to be unclear what's going on.

4. From my understanding (which is admittedly rather limited), postcss is very similar to babel: the idea is to allow you to transpile different syntaxes into "standard" CSS. The analogy goes sort of like "sass/less : postcss :: coffeescript : babel". Again, it's a power tool. Personally, I use Webpack's sass-loader, because I already know SCSS pretty well and I haven't had the time to really look into postcss.

5. How much CSS wrangling have you done in your career? Lemme tell you, CSS can be a massive pain to deal with once your app reaches a certain size, and that can't always be managed fully by methodologies like SMACSS. These are power tools which (are intended to) allow front-end developers to establish some amount of control over a language that's interpreted dozens of different ways, depending on the browser it runs on.

6. That bit did seem slightly extraneous- although I do appreciate that part of the tutorial is going into detail about how I might finagle Webpack to do exactly what I need it to do.

7. Because the output of these tools needs to be different for development vs. production. A comparison in systems languages might be building a C program at low optimization levels and with debugging symbols during a development build, and then a highly-optimized version during a production build.

8. Yes, so many libraries. Other languages (for better or for worse) have extensive testing frameworks, but fully testing web applications also requires means to simulate a browser so you have a good testing environment in the first place. Remember, this is a tutorial for a large-scale web application- automation and consistent testing is crucial unless you actually like paying tons of money for a bunch of QA engineers.

9. All this does is transform pure JSON files into Javascript modules. Literally, this all it does: "https://github.com/webpack/json-loader/blob/master/index.js". Any time you see a loader, what you're getting is a transformation from a source format into a Javascript module (which webpack then compiles into its Javascript bundle).

10. See 8.