It depends what your use case will be really. As @Pyrotenics stated, he is correct when he says
There will always be one way or another to bypass security both on the server and the client. One thing you can do is to lessen the data the client sends to the server.
Just how exactly do you mean that anti-exploit scripts are better than RemoteFunctions/Events? This seems a bit misleading.
I’m not saying it is better, anti-exploits are important in one way or another.
What do you define as an anti-exploit out of curiosity? You make it sound very general.
Here are my tips.
To summarize all the currently posted replies.
Exploiters can access local scripts, but they do not access them directly, but through byte code
Security checks can be bypassed, but depending on your implementation, this may not happen in some cases. Security checks must on the server for mostly authentication purposes and the client for adding a layer of difficulty to those who do not have the right tools.
Thank you all for sharing your knowledge. 
I quoted your replies, that does not claim them as mine. It’s for the sake of learning, not to show off who has more experience.
This is incorrect. Even if bypassable, client-side security measures present a difficulty to most cheaters, who do not have the skills or tools to bypass them. Until a dedicated cheat is developed specifically for your game, cheaters will be heavily restricted by these measures.
Oof, I’ll edit the reply then. Thanks for pointing that out
Several exploit programs out there are capable of decompiling bytecode in a way the result is (except for the lack of comments) identical to the source code. As a result, scripts stored anywhere that isn’t ServerStorage or ServerScriptService can be read by exploiters.
Server scripts cannot be read no matter where they are, their source is never sent to the client.
Just wanted to add something:
(From what I have seen in my previous role as a security researcher on Roblox) most exploits don’t download localscripts. But there still isn’t anything stopping them from taking it as EVERYTHING that is sent to the client (geometry for map rendering, meshes/unions, and of course, localscripts) can be stolen given enough effort.
Anything on the server (including services and server scripts) are safe. That’s it.
.
As for preventing exploits, that’s a completely different topic but many above replies have mentioned how to do this.
What I haven’t seen about protecting models and scripts in this thread is that you can use code that toggles Archivable which will break most exploits, but it’s not a great solution.
I know that everyone’s been talking about LocalScripts, but there’s something I want to address that was mentioned briefly in the OP and skipped over.
It’s the same deal with LocalScripts, except a different process. Workspace is replicated to the client for the purposes of rendering and display, therefore exploiters have access to your geometry data. That’s why maps can get stolen - they need to exist on the client.
Anything that the client can see can also be accessed or stolen. The methodology differentiates depending on what asset is in question.
Just like all the other replies, exploiters can see their local scripts, since it is in the computer, and can bypass any security in their client. On top of that, some stuff from the game server is replicated to the client like the workspace and remotes in order to render the objects in-game and send requests to the server through remotes, which was also mentioned by other replies above. That is pretty much how exploiters exploit, through checking for remotes in their client, getting workspace objects’ geometry, and more.
Exploiters can see what localscripts are present (using a dex-explorer, etc), but they can’t see the source code because it is obfuscated into bytecode. So, unless they are a very experienced programmer, it would be quite hard to reverse-engineer your local source code.
The source isn’t “obfuscated” into bytecode. It’s simply just a compiled version of it, which can be converted back to source code using special programs called “decompilers” which most exploits offer as a function inside them. (just to clarify, the source of the decompilation result and the actual source won’t be identical since whitespace is ignored in bytecode and decompilers naturally prettify it). In conclusion, exploiters are able to reverse-engineer your local scripts.
Yes, but what I mean is, if you were to open up a script without a decompiler, it would be difficult (or impossible) to see the actual code that was used.
But you are right, most exploit toolkits contain decompilers.
Just like it’s impossible to stop people from stealing JavaScript code, I don’t think there’s any good way to stop people taking client side code. The reason that Fortnite and other popular games don’t have as much leaked code is (probably?) because nobody bothers doing anything with half a game, not because it’s impossible to get their code.
The client needs to have the code to run it, and it’s not like Roblox is just sending raw Lua to people free to take. Like Dandy said, they can only access the bytecode.
I’m pretty sure these were only leaked due to a temporary vulnerability that got patched, which is why you’ll only super old versions that are leaked. I only know about Phantom Forces, so I might be wrong about the other three.
You might be right about the vulnerability issue. All of the games that I listed were from 2016 and earlier.
Thanks for your comment.