Thanks for taking the time to read the tracker issue and replay, Rex. Much appreciated.
30KB sounds like a lot however on a production system that file is heavily cached on local disk and within the browser so it really only adds to the network overhead on the first request. After that it's cached in the browser so it'll no longer be sent from the server.
With regards to debugging in the browser's development tools when running the site in development mode Moodle will send source maps back to the browser along with the minified code. This allows the browser to map the minified code back to the original unminified source file which means that you will see all of the code in the browser's source tree unminified and you can still add breakpoints, step through the code, etc as you did before.
I think the experience is actually slightly improved because now the unminified source files are actually split into individual modules and group into directories in the source tree according to their component. This makes it much quicker to find the code you're looking for because you no longer have to scan one giant first.js file.
The build pipeline section was just a set of possibilities. Personally, that is the direction that I'd like to see Moodle moving towards because currently we use quite old technology which forces us to write lots of code to do simple things. This inevitably leads to bugs, slower delivery of features, etc.
I agree that if the costs outweigh the gains then it isn't worth doing however in this case I feel like there is almost no cost at all while providing a significant gain.
I hope that helps! Thanks again for getting involved in the discussion!