I'd say not only the code needs to be local, but it can't make synchronous requests on the network at all until you've completed a task.

One of the underappreciated things about such productive software which enables it to be used without looking is predictable reaction times. Consider the "amazing data entry" video posted elsewhere in the thread, or good old feature-phones. If you have an action that you perform frequently, the key to learning how to do it without looking is to learn how quickly you can feed the input, where do you have to wait for it to be processed, and how long it takes.

It's one of the things I still miss about my last feature-phone (Sony Ericsson K800i). I could do a lot with it without even taking it out of my pocket, because I committed to muscle memory sequences like "up arrow, up arrow, OK, wait half a second, down arrow x3, OK, OK, exit". There's no way I could do this with an Android phone, because input and processing delays are random. Similarly, on the web, if your action shoots out a network request, it can complete anywhere between half a second and half a minute. You can't do actions like these without looking because there's a non-zero chance a delay will mess it up.

And I'll add that a POS should be 100% working even with no internet connection, which it's much more likely to fail than electricity.

POS Developer here. Offline capability (both kinds, with regard to a store server and with regard to an internet connection out of the store) is actually a very important requirement for any serious retailer, but not necessarily 100%, in terms of functionality. Today, you usually want to support some features that are impossible to realize in an offline capable way, like accepting gift cards. For these it's acceptable to be unavailable in an offline scenario. However, this actually creates the next big problem: you need to isolate these services and any connectivity-related errors with them from your offline-capable core ringing process in a way that ensures that your predictable response times of the core ringing process (which are super important for good UX, as the previous commenter already explained correctly) are compromised as little as possible if your online-only feature goes into a failure state - a typical example for "you're doing it wrong" would be waiting for a timeout on an online service on every single request while the connection is down before signaling the cashier that this service cannot be used right now.