People often express frustration with const and immutable in D 2.0 and wonder if it is worth it.
It makes function interfaces more self-documenting. Without transitive const, for all pointer/reference parameters one must rely on the documentation (which is always missing, out of date, or wrong). Note that without transitivity, C++ const is nearly useless for such self-documentation, which is why C++ programmers tend to rely on convention instead.
It makes for interfaces that can be relied upon, which becomes increasingly important the more people that are involved with the code. In other words, it scales very well. People who are involved with projects with large teams of programmers say that lack of const makes their lives difficult because they cannot rely on the compiler to enforce convention. The larger the team, the worse it gets. Managing APIs is critical to a large project - it's why BASIC doesn't scale (for an extreme example).
Const transitivity makes for some interesting optimization opportunities. The value of this has not been explored or exploited.
Here's the biggie. Points 1..3 are insignificant in comparison. The future of programming will be multicore, multithreaded. Languages that make it easy to program them will supplant languages that don't. Transitive const is key to bringing D into this paradigm. The surge in use of Haskell and Erlang is evidence of this coming trend (the killer feature of those languages is they make it easy to do multiprogramming). C++ cannot be retrofitted to supporting multiprogramming in a manner that makes it accessible. D isn't there yet, but it will be, and transitive const will be absolutely fundamental to making it work.
Of course, for writing single-threaded one man programs of fairly modest size, const is not particularly useful. And in D const can be effectively ignored by just not using it, or by using D 1.0. The only place const is imposed is with the immutable string type.
