When I say class, I don't explicitly mean using the class keyword. Also when I say hierarchy, I don't mean only inheritance (composition is also a kind of hierarchy). In my statement, I mean class more like "a kind of structure from which you can create instances", prototypes are similar to classes in that way. Definitely you should still follow some kind of hierarchy when using prototypes... In fact you should be even more careful.
My experience is that hierarchy is more trouble than worth.
And I did like the fun of trying to figure out a hierarchy for existing system. But after a year in use, I woul look at the hierarchy with the 'what was I thinking' look.
So I moved from nesting abstractions with classes to dependency injection to mostly passing well-defined data to functions.
Like, after I understood prototypes in js, I used them for a bit, but then I switched back to passing data-structures to functions :)
There might be another reason why new languages are moving away from this kind of specifying hierarchies. There are already several languages with ecosystems built around hierarchies, so if you are fine with java, you probably wouldn't jump to golang :)
And I worked with large, fairly OO-oriented codebases in JS, and it was fine and I didn't miss inheritance.