One of the problems with David Mertz's counter-proposal for a magic None-aware proxy is that we can't tell the difference between spam.eggs and spam.eggs where one of them is magic and the other is not. So we have a nice, clear, obvious difference in syntax so that at a glance the reader can instantly distinguish between dot and maybe-dot, and you are complaining that it is too clear, obvious and easily distinguishable compared to a regular dot.
That's exactly the strongest advantage in what I suggest!
The special domain where you want attribute access (or dictionary lookup) to be None coalescing is something marked and different from most of what you want in general attribute access. But once you're in that special world of "semi-structured hierarchical data with leaves marked with None" you don't want to be reminded in every operator. It's just what you do with that kind of object.
Naming variable might be a good way to remind readers of the domain. Or comments in the source code. Or putting the special behavior in an isolated function. But effectively, this is a domain you want to enter for a while, then return to the "real world" after some operations are done.
For a pretty good analogy, you cannot tell the difference between 'a+b' and 'a+b' easily either, in isolation. But one of those is arithmetic over the domain of integers, while the other is arithmetic over the domain of a Z(65537) modular ring. Many operations are the same in both domains, but I'd really hate to need a special operator to perform modular arithmetic rather than integer arithmetic. E.g. 'a + b' vs 'a ⊕ b'.
It is MUCH more elegant and clear in both examples to put the work on the *object* that has special behavior, not on the operator. I can see that if you did a very special kind of programming where you frequently mixed modular and integer arithmetic, you might want the reminder. But that's a rare need, and the language itself should not grow that syntax (perhaps something specialized like Sage or Octave might want a different balance, very reasonably).
"Semi-structured hierarchical data with leafs marked with None" is just altogether too special to impose the burden all Python programmers. A None-aware proxy isn't the best possible thing for that special use by any means. But it's pretty good without imposing any burden on the large majority who will never need or use it.
Another similar case is the '@' operator. This is exactly a special domain where an operator indicates special behavior. In principle, you could make objects that did anything whatsoever when they see that, but the name .__matmul__ is pretty suggestive of recommended use. However, nothing in the builtins or standard library define any behavior at all. You can happily program with Python your whole life and never think about this operator. The only folks who will see it are folks who use NumPy and *also* do linear algebra with it. By definition, the objects if this domain are already special, as it should be.
Well, footnote. I think I've seen some other libraries that create a DSL around email that use '@' also. That also feels fine. It's a very different, but equally special, domain where the objects themselves define the special behavior.
If PEP 505 were proposing a regular new protocol for .__none_attr__() or some better dunder name, I would oppose it far less. Specifically, if the behavior of this dunder operator were left to library authors who created such special objects, the danger and bug-magneticism would be much less. I'm well aware that dunders can't get you shortcutting, but modulo that, such a proposal would be relatively innocuous (I'd still be -0, but not really care).