The only way to make it efficient is to have movement handled on the client.Open client sided processing would cause so many other problems, complicate the language, and offer so few benefits that its hardly a feasible solution, especially for this specific feature. In vast majority of cases, it would actually offer far worse "performance" due to the networking requirements alone.
Honestly, if they were willing to take just a few simple steps, we could probably build our own competent pixel movement systems, but since they aren't, we might as well just get them to do everything (its probably never going to happen one way or the other) - not to mention the countless benefits that a built-in implementation would provide.
As for performance/ticks, maybe they could just remove that processing limit to begin with. Instead of sitting around for 99% of an unused tick, that time could be spent processing the next one - that is how most (if not all?) actual games work, and if I'm not mistaken, BYOND's internal processing works that way as well.
It sounds like there are some internal things holding BYOND back when it comes to things like this, but its hard to tell. While I was making my library, I tried to think "what new built-in procs would make this easier?", but I couldn't come up with anything. There just seems to be some general slowness in how certain things are handled. There's no reason why dreamseeker should struggle to run at 30 fps. If these things were improved, it would help everything, not just user-made pixel movement.