Well, there's the "input format" (or rather two), which gets parsed into the internal representation. The input format can be either hex text, which allows dashes in some positions, or binary, in which it's just a bytearray. There's no verification otherwise, unless you treat generation of UUIDs, which allows to specify the type, as such.

Second point: Verifying version information would hardly matter cyclewise.

Well, then it's not an UUID. It's just 128 random bits. If you just want to be the most random possible, you can go 256, 512, 1024, etc. That may be what you want, but you can't say UUID v4 is a "total waste" or "serves no point".

It's purpose is to never collide with another UUID v4, not to be the most unique value ever.

The rationale is that you can use them along with those other versions of UUID that contain nonrandom data.

Assume Bob uses one such not-entirely-random UUID variety and actually makes use of the embedded information. Charlie uses random UUID. Bob and Charlie merge their data.

If Charlie had filled the version bits with random garbage, the merge would poison Bob's use of the embedded information.

Basically, UUIDs are a discriminated union type.

By violating the spec you're assuming you'll never want to use a tool that strictly adheres to the spec. Postel's Law works best because it accommodates some people not following it.