As I understand it, fields are standardized. I don't think they contain the name of the product (I didn't read the spec), but the other info is there, so no need to hit the servers/db on other servers.
As for the quantity of data, Qr codes have special encoding modes depending on the content. The numeric mode uses 3.3 bits per digit, the alphanumeric 5.5 bits per character (45 characters in the set). Switching modes in the stream is supported, though it adds a few bits of overhead.
Looking at the examples, it looks like the scheme is not as efficient as it could be (pesky slashes, alphanumeric at the end), but that's not too bad either.
It was just a quick expression of an idea, presented in the form of a gripe; it's not a formal specification.
As to consumers, and their hardware: People still get new phones and features can be (and sometimes actually are) added to existing phones. I'm not too worried about it as a constraint; things would catch up soon enough.
The reason they're so verbose comes from a few facts.
First of all, it's an existing logistics labelling standard, they've just replaced brackets with forward slashes and put a domain name on the front. So https://example.com/01/09521207311511/21/1234ABDE1235 is just a QR code version of those huge barcodes like (01)09521207311511(21)1234ABDE1235 you see on cases of products in the supermarket.
Second of all, the standard doesn't limit itself to a single date, so they can't identify dates with a simple ,D prefix. It's a kitchen sink standard [1] with 16 different types of date (production date, due date, packaging date, sell by date, best before date, expiration date, release date, first freeze date, harvest date, production date and time...) and just as many options for sizes and weights - so the identifier can be up to 4 digits. /11/ or /8008/
The third thing to know is QR codes pack different alphabets at different densities. Numbers at 3.5 bits per character, upper case letters and some symbols at 5.5 bits per character, ASCII at 8 bits per character. So the 13 characters of of "Apple Fuji Sm" uses about as much space in a QR code as a 29-digit number like "12345678901234567890123456789"
Fourth, you've replaced the 14-digit GTIN with an 11-digit UPC and replace the 13-digit serial number with a 5-digit lot code :)
IMHO the standard isn't going to take over the world, and anyone who says "Barcodes are about to go extinct" doesn't know what they're talking about. But it's not the information density, it's other reasons.
It's just that, sadly, we can no longer have nice things.
If items have unique (ie serialized) codes, then it's safe to assume that those codes will be recorded at purchase (since that's kind of the whole point), along with who bought them (yay discount cards and cashless society).
Now the contents of my pantry describe things like where I've been, when I was there, and/or who I hang out with. Fun times!
Even with cash and without discount cards: One random food label out of a recycling bin can relate all the way to photos of the purchaser's face at checkout, track them walking to their car, and see where that car went. This could happen months or years down the road.
Most of those pieces are already in-place: Our photos are already recorded alongside of our transaction details -- that's been going on in POS world for a long time. Tracking people to their vehicle is a function of Avigilon camera systems. Tracking the car itself is the primary purpose of Flock.
All that's missing right now is serialization records and a centralized database.
I'm sure that nobody will ever finish fitting these things together into a cohesive system and that nobody would ever use it with ill intent.
It probably would never happen anyway, since there's not a single retailer on Earth who would ever exchange this kind of data for an upgrade to their in-store surveillance systems and a monthly check. ;)
(And we still don't get directly-useful consumer information into or out of these new 2D barcodes. I love losing.)