This sounds like it would force a return to Store-And-Forward[1], where the switch waits for the entire frame to load into memory, before forwarding to its next hop. Waiting these few milliseconds doesn't sound bad, until you consider that's added to each packet, reducing (e.g.) application performance.
Also, the difference between cut-through and store-and-forward is generally in single-digit microseconds, not milliseconds. A good rule of thumb is ~1 us/KB at 10G.
The FM4000 looked at 64 bytes before forwarding (IIRC). The 1st Broadcom chips that did cut-through were the Trident line. They looked at something like ~200 or ~500 bytes before making a forwarding decision (sorry exact number is not in cache anymore). They cut that down with the T+ chips.
The funny issue about cut-through is that it will forward a corrupted packet. Trying to pinpoint the source can be fun.
With static webpages, etc, old school internet the latency was not a big deal. The improvements in switching with cut-through and low latency were a game changer for storage, video, etc.
In other words, if you want to have a firewall rule of "drop tcp 135", in ipv4 you can just look at bytes 0x24-25 (for Ethernet). IPv6's extension-header mechanism means that the header has a non-fixed length, so you need to do work for the same effect. Given that firewalls are critical in a world without NAT, this can be a scary prospect.
Part of the blame falls on vendors who go "well, IPv6 is fringe so we'll just do all firewalling in software." The protocol is 20 years old, it's time to design the silicon.
IPv6 requires you to loop through all extension headers to reach layer 4, and you need to know about a handful of those extension headers as not all follow the same format.