• Client side effects: You can do local/client-side effects without hacks; parts can move or appear or change so that each player has a different view of what's going on. This is particular useful for animations and stuff.

  • Lighting / Fog can easily be unique to each player
  • Walls / gates can be open/closed uniquely to each player
  • Animations can be done smoothly without interfering with other players' view of the world

• More network bandwidth: At the same time, doing local effects won't slow down other clients, since anything done by a LocalScript doesn't need to be replicated to all of the other players

  • Effects like spinning an item mean you have to send 30+ messages/second to each player. This rapidly replaces other, more important changes (like enemy/obstacle positions that move). If you do this locally, then nothing needs to be sent over the network, makings things clear for everyone else (this can only be done with odd hacks without FilteringEnabled)

• More secure: Your game is more secure -- even if some players can exploit ROBLOX, most likely whatever they change will be ignored by the game and your other players won't be affected

  • ROBLOX will only stream places that have FilteringEnabled on

• More transparenty: It's easier to think about programming over a network -- ROBLOX is a distributed platform. With FilteringEnabled on, it becomes clearer exactly how the pieces fit together.

What FilteringEnabled stops you from doing

• LocalScripts can no longer directly affect the world in a way that other players can see.

• Normal Script objects can no longer directly affect any players' PlayerGuis.

Instead, LocalScripts / Scripts order each other by communicating using RemoteFunctions and RemoteEvents.

This is most problematic because of the various services/properties which are only available on the server/client, but it's still easy to use RemoteEvents to solve this.