Sure . . . I mean, C doesn't exactly have namespaces, and neither did PHP at first, and you can write code in them, so it's not that it's somehow not possible to uniquely name functions. But it's pretty annoying, and I'd say that many people who are used to modules and namespaces miss them when they move to a world that doesn't have those things. They exist as A) syntactic sugar, so that you can just say assign_user_activity() instead of my_company_my_project_assign_user_activity and B) as a strong organizing principle (potentially that has tooling around it). The former point is just annoying; my argument was that the latter is really the point of modules or namespaces.

Maybe I want to find all the functions related to assignment: how do I do that? Do I just look on disk? Do I use tags or metadata? Do I assume some naming convention? It's a problem you have to solve somehow, and solving it requires effort, because it's an explicit organizational effort. Modules or namespaces or packages or classes give you a way to say "this stuff goes together" and to encapsulate and abstract large units of related functionality, and to do so in a way that tools and programs understand. In a Java IDE, my IDE will auto-complete all the functions on a class; in a REPL I can just print out all the methods on an object. That's a useful organizing principle, and it's one that you lose if you totally flatten the namespace.

You could argue that organization isn't one-dimensional or hierarchical, which is what namespaces and such force on you, and it's a reasonable statement. But replacing it with nothing explicit and relying on extensive developer metadata and documentation so you can search for things? That seems even more idealistic. When was the last time you saw every single function, even private ones, documented and tagged so correctly and up-to-date on a real-world, large-scale project that you'd rely on them to serve as the only organizing principle in your application?