Nameclashes with std /are/ common, and get more common as the standard
library increases in size. The whole point of having the standard
library in the std:: namespace is that the C++ committee are free to add
whatever names they feel appropriate, without fear of breaking existing
code or limiting other programmers.
If you have a global "using namespace std;", and there are clashes, then
it /might/ lead to a clear compiler error. But it might not - it could
well be that overload or template resolution simply leads to the wrong
function being called, with no warning until you get obscure effects
during testing.
And even if compile-time errors were guaranteed, what help is that when
you take a large existing C++14 code base that has been extensively
tested and debugged, then suddenly there are problems and collisions
when you move to C++17 or C++20.
Namespaces were added to C++ because at that time, decades ago,
identifier collisions were a big problem in large C codebases. They
have been a major tool ever since. Adding global "using namespace"
directives, especially for namespaces that are not fully under your own
control, is throwing out that tool.
It is fine to have "using namespace" in smaller scopes - such as inside
a function. Occasionally you might want to import a namespace into an
entire implementation file (not a header), but not for "std". If you
had the habit of putting "using namespace std;" /inside/ main() or other
sample function, you'd see far fewer objections.