Ok, thank you for the responses so far. All very good and useful feedback, but I want to start a conversation for some of these topics so we can get the best result possible. So, just to share some of my views with you all to show you what problems I was solving with each aspect of mastercomfig, just so you can maybe think of another solution or compromise, or at least become more sympathetic to what I'm trying to do. This isn't me trying to convince you or change your mind, only to share with you my perspective so that we can better communicate the way forward to solve these issues you guys brought up so far.
mastercomfig updates very frequently. It can be hard to keep up if the update process is anything other than drag and replaces the VPKs in your custom folder because you have to redo your changes every time you update. I thought it would be a worthwhile compromise to have an initial long context switch to VPKs from cfgs and a very low barrier to updating so that people wouldn't be inclined to stay on a super old version of mastercomfig. Additionally, mastercomfig is not just an autoexec config. It has lots of other modifications within TF2's script files which can only be loaded in the custom folder. For example, I unlock usually hidden/protected commands for disabling sound DSP, disabling ropes completely, decreasing water splash particles, and more, as well as adjusting what content is preloaded to have memory be used better. Finally, lots of people would complain that they didn't know how to switch between presets easily or remove the config back when it was text files, and now it's a simple VPK removal process. But even with all of that, I have actually started to release ZIP packages of the config, you can find them in the advanced downloads section, for those who don't mind what I think is a headache, and they include comments.
Now, about comments... Comments are all still there, on the GitHub page as well as in the ZIP package. They're only removed from the VPK since there's no reason to open up the VPK, and to save space. Comments were doubling or tripling the size of the VPKs and given that most people aren't even going to open them and there isn't a reason to just to check comments, they're stripped out there.
mastercomfig uses class configs due to a bug or feature in the Source Engine which does not execute game.cfg on map joins in multiplayer clients. Maps have some entities in them sometimes which set values of console commands which mastercomfig sets: detail prop distance values, and water distance values. The class configs are meant to be a workaround to set these settings to get more FPS by setting them to the config values after the map sets them. Additionally, they do some memory cleanup commands so that the game doesn't get bloated over time on long running games. I've tried making this process easier, by making it so you only need to create a user folder where your class configs are and then drag them all in there, instead of making it renamed.
mastercomfig has a modules system which is completely optional, you can use the autoexec in a user folder to use individual commands. With VPKs, the values in the config are static. Modules are used so people can get around having to set a command to a different value from the config, which may cause a system reload and thus longer startup times. Modules are able to replace what the config runs, so that you only run the command once.
Thank you for reading :) I hope to see your thoughts soon on how we can address some of these things in a way that makes everyone happy.