C# does not mandate having one class per file. (Java doesn’t for non-public classes either.) While I suppose many (most?) devs/projects have adopted this rule, there are cases where it makes more sense to keep related stuff in one file.

C# also did not mandate having one namespace per file. Devs have adopted a "one namespace per file" rule because it's generally a good idea. So now the new "file scoped namespaces" allows only 1 namespace per file; and if you want more than that, well then your namespace can't be file-scoped, by definition. You can still use namespaces with { } in that case.

The same _could_ be done with type declaration such as classes and interfaces. If it would be beneficial idea is another thing.

Sure, but “one namespace per file” is a much more obvious idea than “one class per file” (especially with C# IDEs aggressively tying namespaces to the filesystem layout).

What draw backs are there? I can't think of any beyond the initial WTF factor of seeing functions living free of braces {} prison.

Multiple classes per file with would still be an option of course.

Namespaces allow for logical grouping

How would you group things without namespaces?

by their physical location?

No, by their namespace. Never suggested removing namespaces or classes. Just removing the "indentation".