"Continue supporting the time-honored usage of volatile to load and store variables that are used for shared memory, signal handling, setjmp / longjmp, or other external modifications such as special hardware support."
Which is what people want and use volatile for in the vast majority of cases. Removing that functionality would render driver, OS and embedded development a pain.
The solution was to replace volatile with a compiler intrinsic load and an intrinsic store. Those get special treatment in the code generator, and the rest of the type system does not have to carry the burden.
It would be worse than "a pain", it would actually make it impossible. There is no way other than "volatile" to guarantee that a load or a store to/from a particular memory address happens at a particular time (AFAIK).
In any case, the scope of the variable was not the point of the question. The behaviour doesn't really change if you make the variable a static file-scoped one.
volatile is a weak tool in the face of all the stuff that hardware folks do to achieve performance or cost goals. Most of the platforms I've worked with use abstraction layers that bottom-out in compiler intrinsics or assembly language. I'm deeply suspicious when I see code using bare volatile declarations, as the code is often wrong.