Remotes are used to communicate from Server ↔ Client. They were referencing Signal implementations that act similarly to BindableEvents (which are not the same). You can also make a module script that stores signals for other scripts to view, but for clarity I will only be talking about RemoteEvent wrappers.
Because you said that you don’t care about compression, in your case, RemoteEvent wrappers are useful because they let you access Events that communicate from the client to the server from one point. (More about why this is better later)
But the main selling point of RemoteEvent wrapper modules found on the DevForum is the compression (like you mentioned) and the amount of RemoteEvents they use. This helps with the bandwidth altogether. Because the libraries that do compress the data typically ask you to define what types you pass in advance, people tend to put all the remote events declaration in a big RemoteEvent handler.
Claims from Blink:
Memorize? Not really, it’s the same thing as changing the name of a RemoteEvent. This is exactly why people do RemoteEvent wrappers because it makes it easy to reference the same RemoteEvent without needing the path to it (e.g RemoteEventHandler.Event1 instead of game.ReplicatedStorage.Events [...]). I would argue it’s easier to do the first way!
If you’re trying to make a game and want to structure it correctly, having a RemoteEvent handler will make it less confusing and more structured. I highly recommend you doing it this way, especially if you’re working with groups of people.
But know that RemoteEvent wrappers found on the devforums actually do more than the simple implementation shown in the video, and you should get familiar with them.