When you are writing this const in the "const std::string &name" you are 1) constraining developers from breaking things 2) making the code more efficient 3) providing clues to other developers 4) providing clues to optimizer.
All of these points are important to some degree. And it is just the same, when you are writing this assignment.
And writing efficient code that provides all these clues in every way possible (including consistently and meaningfully arranging the white spaces) is certainly a good idea. Funny thing, that with experience it doesn't take extra time to do that. You just write it, and it comes out in the right way: readable, efficient and optimal down to CPU microcode and aligned memory accesses.
Sure, putting const in parameter declarations is easy to do. It may even buy you a little bit of speed because the compiler is a little bit clearer about pointer aliasing and whatever. But it's not going to make a difference in the equivalence classes of slow code / fast code / Really Fast Code.
Serious hardcore optimization usually involves changing the way the problem is solved to something different than the way the old code thought about it: either constraining the problem space further, or attacking it from a different direction. This usually involves rewriting everything since there are so many cross-cutting concerns. Sometimes one has to do this several times to figure out which way is really fastest. Microoptimization things, like whether you used const somewhere or not, are much smaller details that have correspondingly small effects.
For code that one isn't specifically optimizing, speed probably doesn't matter. There was an exception to this, where we hit a little bit of a bump in the late-2000s on platforms with in-order CPUs like the PlayStation 3 and Xbox 360, because they have such a high penalty on cache misses; this tended to make general-purpose code slower and result in much flatter profiles. But now we are pretty much out of that era.
In general, const is more of a protection than an optimization. This is especially true heading into the massively parallel future, where const just sort of tells you whether some code is known for sure to run safely in parallel or not... and running safely in parallel matters tremendously more to overall speed than the number of instructions in that bit of code, or whatever. (Anyway, C++ is not at all a viable language in the massively parallel future... so that is going to be interesting.)
Go ahead and apply const as you see fit, but don't expect better code out of it.
So, I'd rather leave these clues to the compiler/optimizer.
Since the very thing that const is supposed to indicate is "no writes", and it doesn't do that, const annotations provide zero information. Thus they add no scope for optimisation.
constexpr isn't relevant to this issue. Since sane programs don't spend any appreciable time calculating constants, it's also rather uninteresting for the purpose of making programs run fast. As far as I can see its only practical purpose is to expand the set of fixed terms allowed as template arguments.
Either way, you are right, and my comment should have been: 1) constraint 2) providing clues to developers 3) providing clues to optimizer.
I agree that const is useful for the other reasons you mention.