19 packets per frame is the theoretical max that a full speed controller can support. Not all controllers can manage this. It also depends on the controller, roughly how complex the controller is and how many accesses to memory it needs to make and how fast the memory is. Most controllers are PCI, so the PCI latency is important in how fast memory appears to the controller.
First was UHCI. This uses simple memory access and the controllers are relatively simple. Most UHCI can manage 18-19 packets per frame.
Next was OCHI, these are considerably more complex and require more memory accesses. They can manage something like 15-17 packets a frame.
There was a bug in an early OHCI controller, and the workaround for the bug in effect slowed down the controller. So a popular early OCHI implementation would do 14-16 packets a frame. This shipped in many systems.
A later implementation was just plain bad, and could only manage 14-16 packets a frame, but as it was as fast as the existing implementation (when slowed down with the workaround), no one noticed. This was also popular and shipped in many systems.
When this slow implementation was incorporated as the companion controller of an EHCI chip, no one took much notice of how slow it was and one implementation put three PCI bridges between it and memory, and you're lucky to get 12 packets a frame out of one of those.
With USB 3 there was a change in the controller implementation, they use XHCI. XHCI controls full speed (as well as low, high and super), and uses a very different architecture so it doesn't depend on memory latency anymore. I think XHCI controllers tend to the higher end, 17-19 packets a frame.