The fact that it's C++, where the prototypical user believes that they shouldn't pay for what they don't use just makes things worse. Everything being optional means there can be very few synergies in language or standard library design, because if feature A needs feature B to work, people who want A but not B will complain. C++ "chooses" either by omitting both A and B, or creating some low-level error-prone features and hoping users won't chop off too many fingers trying to build their own incompatible versions of A and B. An ill-designed misfit language is all but required by the dynamics of the situation.
If you do like const (which I do) then you can put it in pretty much everywhere, except if you are dealing with a library that isn't "const correct", but then a bit of type casting will save the day.
That's a big advantage of lots of the C++ features - if you don't like them you can often just ignore them.
In retrospect, it might have been better to have a keyword for things that can change. This goes equally for Java and "final". Making immutability the default and mutability opt-in makes for fewer bugs and more reliable programs.
Arguably, this is what Clojure does where you have functional, immutable constructs by default with ways to declare things that can change (refs, etc.).
The thing is, this kind of code isn't an exception in the C++ world. C++ is made for problems where performance matters: image processing, compilers, browsers... immutability works for Clojure, but Clojure is a lot slower than C++. It's more of an "enterprise software" language.
* Use const everywhere
* Use casts everywhere
The same thing happens if you use const and your libraries don't...
One problem with const-correctness is C++ uses "const&" to mean two different things: it could mean either a reference to a persistent object you're not allowed to change, or it could refer to a temporary object which you're prevented from changing because the changes will disappear. The problem is it conflated access control with lifetime. It would have been better if there were a "temp" keyword - although the last thing C++ needs is more combinatorics of type decorators.
On the subject of consts, though, C++ simply enforces const correctness more, but doesn't the same criticism of confusing const apply to pointers in C as well? You can just as easily declare a "const * const" in C as in C++. So I fail to see why Zed Shaw writing something in C gets him away from that "problem", unless he doesn't write const correct C.