That was before the maturation of modern isotopes...where unstable antiforms simply have no representation you can put in a variable.
As of 2025... to put forth the spirit of the proposal today, it would be:
"I think the frames should speak in a uniform meta-protocol. Then the mechanics that turn non-^META parameters into stable values should be done by the function when it's called."
Profound Idea 
Profound Implications
This concept is that the central mechanics of function argument gatherering and dispatch always uses meta-parameterization, and it's only at that "last mile" of a FUNC or LAMBDA invocation that it does the convenience of un-meta-ing parameters (the ones you didn't mark as ^META) for you.
In the past I've complained about not wanting to make more ^META variables, because they are a a pain to deal with. For instance, if APPEND takes its value-to-append argument as ^META, you'd have to write:
append-reverse: enclose append/ func [f [frame!]] [
if any-series? unlift f.value [
f.value: lift reverse unlift f.value
]
return eval f
]
I cited this kind of hassle as a reason why I was afraid to make F.VALUE meta, even though that would be the right answer to make it work with appending a VOID state that can't be put in a variable.
BUT I noted in the thread above the new power-tool of metavariables. That makes it better in more ways than one:
append-reverse: enclose append/ func [f [frame!]] [
if any-series? f.^value [
f.^value: reverse f.^value
]
return eval f
]
That's a big improvement. And the peace of mind of knowing that APPEND can change its mind over time about whether it wants the variables to be meta or not when the function starts running... without affecting frames... is really nice.
No ^META Parameters In The Interface Is GOOD
There's tremendous benefit to removing the idea that a parameter is "meta" from a function's public interface.
HELP doesn't have to show it. Callers don't have to know it. They can just look at the type signature... if they see PACK! or something in there, then they know "oh it takes packs, may treat them specially".
But it's not just ENCLOSE that would be affected. Other function composition operations would too, such as ADAPT:
append-reverse: adapt append/ [
print "Hi, I'm an adapted APPEND!"
if series? ^value [^value: reverse ^value]
]
Basically, the adaptation runs on the frame before that "last mile" conversion. So it's subject to the same rules. (If we weren't going to make it subject to the rules, then ADAPT would have to be able to query the function it was adapting about the meta-parameter status. This would be like exposing it in HELP.)
It's a little bit sad that you wouldn't be able to just copy and paste code out of a FUNC body and put it into the code of an ADAPT. But I think the higher calling here is to say that the "meta vs. non-meta parameter convention" is just an implementation detail of things like FUNC and LAMBDA.
foo: func [x ^y] [...]
=>
foo: fundamental-meta-func [x y] [x: unlift x ...]