It sounds like you're saying: "C needs internal linkage because it doesn't have namespaces, so the choice is between writing
inline int yexuans_detail_namespace_private_helper(int x) { return x + 1; } // external linkage, still practically invisible to other TUs because they won't guess this secret name
and the latter is obviously too ugly, so internal linkage serves a valid purpose in C. But in C++, the choice is merely between
static inline int private_helper(int x) { return x + 1; } // internal linkage, invisible to other TUs
and
namespace yexuans_detail_namespace {
inline int private_helper(int x) { return x + 1; } // external linkage, still practically invisible to other TUs because they won't guess this secret name
} // namespace
yexuans_detail_namespacewhich is more ergonomic than `yexuans_detail_namespace_private_helper`. So C++ doesn't need internal linkage at all, and we can just get rid of it."
But that's silly. For one thing, internal linkage helps the linker do its job efficiently. And for another, there's still an important difference (to some programmers) between "invisible" and "practically invisible." If we have a foolproof way to hide a symbol from other TUs, we should use it.
Reading between the lines, I hypothesize that you might think there's some difference between
static inline int f() { return 42; }
and
namespace /*unnamed*/ { inline int f() { return 42; } }
There is not.