The longer I’m in the 3D printing game, the more bad recommendations I see 
The reason some people recommend doing it in the firmware is that they expect you’ll redo your firmware again, and again, and again, and again - which just isn’t practical for most people. I believe that it would make your life easier if you were able to run a nightly build, and never have to tweak an option again - because you fix the problem at the source - a physical issue after a modification. If the motor turns backwards, you fix the motor.
The legacy that changing these things in firmware just for your printer is that every time you try a new firmware, you’ll have a 50/50 chance of it working - as you’ll still need to reverse the E stepper with every build you do.
Switch the two wires in the plug, and you only have to worry about it again if/when you change to a non-geared extruder. To me, that’s a much better long term solution.
Regarding the different methods of firmware on my site - there’s a few things to keep in mind that may not be immediately obvious.
-
The daily builds are optimised with around 2 years of tuning, test prints and experimentation.
-
The firmware builder begins with the default configuration for the printer selected, and then allows you to change options to suit your build. It expects that you know more about what you want to build and therefore can tune more towards what you want.
There’s a lot of behind-the-scenes stuff happening with the firmware builds - as I’m currently working on migrating the daily builds to use the Firmware Builder build system.
The build system used in the Firmware Builder is newer, more robust, more scalable, and much more capable - so eventually, the daily builds will be moved to using this build system.
The UI for the Firmware Builder will improve over time - and give access to more options, but the pressing matter for me right now is the migration to a single build system - which also means only having to maintain one build system and free up more time to improve other things.
As for the BLTouch support - I can see you selected a UBL bed levelling - and that needs special G-Code and support for in the DWIN screen subsystem. This isn’t supported in Marlin. There is support for bilinear levelling, and that should work as intended.
It may work in Jyer’s fork of Marlin, but to date, there has been very little in the way of Jyer submitting his work for inclusion in the main Marlin project - as such, its a very different project from the main Marlin code base.
Sorry its a long reply - but I hope its helpful