If I have 1.2.3.4 in ipv4 world, I want 1.2.3.4 in ipv6 world instead of a random new address. I want another ipv6 host to be able to send dst=1.2.3.4 and have it go directly to my ipv6 host. 6to4 isn't comparable to that, it's for translation to/from v4 like you said.
Locked down OS and hardware, or not usable for general compute for some other reason. 20 years ago you could have a gaming PC with discs like a console, but again the console was locked down.
A game console is also locked down from the user, usually because the company is selling hardware at a loss, wants to maintain control, and wants to prevent cheating in online games. May also have exclusive games tied to the hardware.
The regular proto-to-python feels fine to me. I quit Google a while ago and have still been using protobufs, and the main things that usually make teammates wary are: 1. No way to load .proto specs at runtime (there are GH issues about this) 2. No clear and easy way to use it with HTTP/1.1. Neither is specific to Python.
Both of these might sound silly if you're used to protobufs, cause you can build little helpers for both, but plenty of people have never used protos. They would shrug proto away if there weren't someone like me to attest that it won't get in the way. It seems like Google focused on gRPC, but the real prize for adoption would've been going after the simple HTTP+JSON use cases. Like an official protobuf Express middleware.
6to4 or NAT64 isn't the same thing as what all those IPv4+/5/7/8 people want, if that's what you were referring to. You don't actually own the IPv4-mapped-V6 address, as in packets don't get routed to you, they go to a relay that was notoriously flaky.