This just seems like a bad idea, sorry to say. Maybe have it detect if OptiFine is installed, and if not, disable it by default?

This is done to fix a lot of bugs but why not.
Making the fields & methods public is to fix compatibility issues.
(This also helps fix compatibility issues with snapshots and not only Optifine/OptiFabric)

And in terms of security, it doesn't add anything because any access check can be easily bypassed with C++ code (Java allow mods to inject .dll/.so to the current process) and any mod can run any executable on the computer. (If your antivirus doesn't prevent it)

Also, in theory, it also reduces CPU usage since the JVM has to execute less C++ code to check accessibility.

But Yeah I will try to do a switch for the next release since it's not always required.
But it will still be enabled by default.

And you didn't explain why this is a bad idea but I still try to respond of what you might think this is a bad idea.
If you wish to respond to this or explain more in details why you think this is a bad idea I will be happy to respond.

It's just that messing with so many classes at once seems like a good way to get into a sticky situation, though this hasn't really happened yet (excluding the time it affected all classpath entries), so this is getting closed.
Thanks for implementing the feature, regardless.

Once it has caused issues because of field access and I fixed it ( See #4 )

And even if this should not cause problems having a switch to be safe is still helpful even if I doubt there will be a need to use it.