I think the second part applies even more to namespaces, and the general ideas of public and private that are showing renewed interest at present.
I have multiple thoughts in some order:
Why introduce a lobotomized class? Every time I learn something new about how classes work internally I’m impressed at the forethought that has been put into them over the years. eg descriptors, metaclasses, __getattribute__ and __getattr__, etc. It seems a lot easier for one to just use a class and ignore the features that one doesn’t currently need (which one probably is using behind the scenes, just with sane defaults) than to add a primitive ‘namespace’ which would be a step backwards.
I agree with
in that classes can be used as ‘namespace’ containers for constants and static methods, if not a module. Both are “just regular programming” not an anti-pattern; it doesn’t have to explicitly say ‘namespace’ on the tin to behave as a namespace.
When thinking about namespaces being imported across multiple files, it seems like an unnecessary extra layer of indirection on top of importing the files / modules themselves. It’s reinventing the wheel of defining a src/MyModule/constants.py, replacing it with namespace constants: inside eg src/MyModule/__init__.py.
It seems easy to rename a constants.py → constants_renamed.py and use import constants_renamed as constants, or rename a class Constants → class ConstantsRenamed and use from MyModule import ConstantsRenamed as Constants to keep git diffs small. How would one rename a namespace and keep lazy compatibility?
Would namespaces be reusable / extendable?
namespace consts:
x = 1
namespace consts:
y = 2
C++ allows reusing namespaces (not that I wish to encourage any C++ nonsense) but isn’t that ultimately just for name mangling?
Related to the public and internal scoping thread, I’m of the (naive?) opinion that public, private, protected, friend access modifiers smell like 90s (P)OOP: corporate gurus and fizzbuzz professors trying to evangelize and restrict people to their dogmatic code style. It just leads to fighting over ‘I wanted to use that variable but you made it inaccessible’ which is part of the “actively detrimental” we should avoid 
I like OOP, but I don’t think that we should add access modifiers to Python just because other languages have it. I’m in favor of the view: “leave it at _my_variable with an underscore and ‘consenting adults’ can decide if they want to use it”. Namespaces feel like the same issue as you say. Next there’d be pushes for ‘protected namespace’-like behavior that only the “internal” modules can access, with shortcut functions and testing goodies locked behind an access modifier glass case.
The only issue I see addressed by namespaces is less @staticmethods and
which I +0 agree with. JavaScript allows this to behave as the class within a static method, but then again how JS handles this is historically infamous.
class Vec4 extends VecN {
constructor(x, y, z, w) {
super(x, y, z, w);
}
static from_vec3(v3, w = 1.0) {
return new this(v3.x, v3.y, v3.z, w); // 'this' is Vec4
}
...
}