(4) understates the problem, the user is required to memorize 4823 items without having a way to find the item they are looking for. If you try to solve the memory issue, the system must become more complex.
The way it happens in places with low number of SKUs (< 10k) is people who're new typically search a lot in the beginning, but over time, they'll learn the most frequently used item-codes without any deliberate learning. They also get really fast at the keyboard. This was my experience building DOS-based POS software for small supermarkets and grocery stores.
If there are a much larger number of SKUs, or if the item-codes are provided by the manufacturer (like in the automobile spare parts business with 16-digit alphanumeric item-codes), you have to key in them manually.
A paint store I built software for had a huge number of SKUs, but they were renowned for their customer experience. This was made possible by putting new employees through a training whose qualifying test is to key-in a bill of materials at a really fast pace. They also chunked item codes into well-defined easily-learnable categories. This was the grouping: [Manufacturer, Product, Packing, Color, Code]. There would be < 20 manufacturers, of which only 4 or 5 are frequently used. Same for product. Packing and Color were more of attributes, but were easily learnable and helped uniquely identify a product.
I am having trouble imagining how a keyboard-centric interface would require less key strokes than the number of screen-taps for a POS system designed for a pizzeria. For instance, to add or remove a single ingredient to a pizza in the touch-screen POS system it required a single tap. In a keyboard-centric POS system, assuming the ingredients are identified by id starting at 1 through 75, most ingredients would require two keystrokes plus the enter key. My personal experience leads me to believe that specialized touch-screen POS systems certainly work well for some of the more complex restaurant menus.