It doesn't seem like it. Linux has a habit of multiplexing alternate functions through a single handle with additional and somewhat scary methods like ioctl. Plan9 manages this with servers, directories, and more than one path available for a single resource depending on what you're trying to access. This is far more sane.
> With time, we should have seen a lot of ugly interfaces resulting from this limitation.
They don't seem any more complicated than they need to be. Compare implementing a fuse server vs implementing a plan9 server. Yet I don't see where all of this complication adds anything or enables implementation of technologies that couldn't be implemented on plan9 with a few additional paths.
> People could no more keep up with simple general designs. And to squeeze every bit of performance,
These are contrary goals, and I'm not sure what you mean people can't "keep up" with "general designs." What is there to "keep up" with? And in exchange for that performance we got one of the most insane /class/ of unfixable CPU bugs ever imagined.
> And this is how we ended with the extreme fragmentation and heterogeneity we have in Linux,
And yet.. many of these systems are now being unified into generalized file descriptor based systems, that have wacky open methods, but boil down to allowing simpler interfaces through read(2) and write(2).