If it doesn't have error checking and checksums, it shouldn't be relied upon by the general public.
Let's say you're at a restaurant, they have one of those stupid QR codes to view the menu (I really wish they would print the damn menus, but that's another story ...). Why not just an URL of "myrestaurant.com/menu" and you just scan that URL? Who would typo-squat an alternate menu and paste it on the restaurant tables?
If there's a venue in which typo-squatting is a potential threat, QR-squatting would be an even bigger threat because even if only 5% of people have sharp enough eyes to spot a typo squat, probably only 0.0001% of people are good at decoding QR codes in their brain and would spot a QR squat. The typo squat is easier to spot.
If you really wanted, we could also establish an optional checksum protocol for URLs e.g. http://myrestaurant.com/menu#cs=123
If the checksum fails, the phone can try (a) all possible 1-2 character edits for error correction, which should take only a couple milliseconds (b) auto-Google the URL to see if there is a fixed version of the URL (c) error out if both of the above fail.
I'm suggesting that for real life we could just use URLs and OCR instead of QR codes.
No, because that's not reliable, and way more complicated and error-prone.
It's the same reason bar codes are used instead of directly the id they code.
Your earlier solution doesn't convince me. It's interesting, but not practical, and reading the URL should work even if internet is off or the server is down.
(Having a checksum next to the URL may start making OCR practical though)