Your example is a really poor one. The volatile keyword was only used to provide hints to the compiler on whether or not it could apply some optimizations. Omiting a volatile keyword is perfectly backward compatible, as is compiling code without support for volstile. Thus the only practical consequence of adding/removing random volatile keywords from your source code was how your build could (and not should) be optimized.
That's a far cry from, say, remove malloc().
On MSVC, volatile has traditionally meant something akin to atomic. It still will, regardless of what the Standard says and other compilers do.
"Can't" is a big word when applied to the ISO committee. They would want to consider the magnitude of consequences. Since all implementations would provide a "make like before" switch, consequences would be limited.
No, at best you saw code that expects the compiler to not apply specific optimizations that C++ doesn't suggest or enforce. It's a compiler issue, thus if anything that code needs to be compiled accordingly.
https://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf
class foo {
void i_am_deprecated() volatile;
void i_am_also_deprecated(volatile int);
void i_am_not(volatile char*);
};