I held the same position as you until quite recently. Unfortunately I've changed my mind on this somewhat. I've found it introduces too much friction in practice to be generous with const everywhere. A few reasons for this that I can remember off the top of my head are the following (there are probably more that I'm forgetting):
(1) Constifying variables hampers your ability to move from them (including RVO), which you still frequently want to do even in cases where you don't otherwise mutate the object. Which is obviously bad for performance. Now your solution might be "ok, so don't put const if you plan to move", and sure, you can do that, but then your variables and parameters start becoming an inconsistent mixture of const- and non-const types. Not the end of the world, but it's kind of jarring for a reader (read: increased cognitive load, confusion, etc. during maintenance) when they wonder why X is const and Y is mutable despite the fact that the problem should treat both of them as const. Now, if this was the sole downside, I would say might still be worth it on the balance, but it doesn't help the situation when there are other downsides.
(2) Conceptually, constness of object types in a function signature is an implementation detail callers should be unconcerned with, but language-wise, it's also encodable in the prototype. The practical implication of this is that the prototype ends up going out of sync with your implementation, and you'll want to fix them up so they match. (Not just for aesthetics, but because it also helps with tools, say grep.) The compiler doesn't necessarily complain for object parameters, but if you don't fix them then you end up with inconsistent signatures that are further confusing at best. Not only does this get quite annoying, but fixing it also forces the recompilation of all callers, which is yet another thing that slows down build times unnecessarily.
(3) It's practically impossible to get other developers on board with this even if you ignore all the other issues. Too many people just don't care enough for the advantages to change their habits on this issue. If anything, you'll be forced to remove "excessive" const for consistency with the existing codebase.
Now there are obvious advantages, and I could honestly argue for either side, but the friction starts getting old. It's just not a clear-cut case in practice, as much as in theory I want to agree with you (and have in the past).
Agree about 1, about 2 I Think there isn't anything wrong about the prototype differing for top level qualification from the implementation which is perfectly legal. I normally grep function names, if I want semantic search I use lsp.
Regarding 3, eh, leading programmers is like hearding cats.
(1) Constifying variables hampers your ability to move from them (including RVO), which you still frequently want to do even in cases where you don't otherwise mutate the object. Which is obviously bad for performance. Now your solution might be "ok, so don't put const if you plan to move", and sure, you can do that, but then your variables and parameters start becoming an inconsistent mixture of const- and non-const types. Not the end of the world, but it's kind of jarring for a reader (read: increased cognitive load, confusion, etc. during maintenance) when they wonder why X is const and Y is mutable despite the fact that the problem should treat both of them as const. Now, if this was the sole downside, I would say might still be worth it on the balance, but it doesn't help the situation when there are other downsides.
(2) Conceptually, constness of object types in a function signature is an implementation detail callers should be unconcerned with, but language-wise, it's also encodable in the prototype. The practical implication of this is that the prototype ends up going out of sync with your implementation, and you'll want to fix them up so they match. (Not just for aesthetics, but because it also helps with tools, say grep.) The compiler doesn't necessarily complain for object parameters, but if you don't fix them then you end up with inconsistent signatures that are further confusing at best. Not only does this get quite annoying, but fixing it also forces the recompilation of all callers, which is yet another thing that slows down build times unnecessarily.
(3) It's practically impossible to get other developers on board with this even if you ignore all the other issues. Too many people just don't care enough for the advantages to change their habits on this issue. If anything, you'll be forced to remove "excessive" const for consistency with the existing codebase.
Now there are obvious advantages, and I could honestly argue for either side, but the friction starts getting old. It's just not a clear-cut case in practice, as much as in theory I want to agree with you (and have in the past).