> You're describing a fairly narrow subset of subclassing; notably one that is (as you point out) almost equivalent to composition.

I'm not sure why you say this is a narrow subset. I'm describing a way of thinking about inheritance (inheritance is like composition + automatic delegation). That way of thinking can be applied to any subclassing operation, and I think it's instructional to do so. It can help you see what's a good idea and what's not.

Let's run down the list. Assume you have a class A with a method foo() and class B with method bar().

The equivalent* of "A extends B" is:

    function A() {
      this._b = new B();              // equivalent* to calling superclass constructor
    }
    A.prototype.bar = function() {
      return this._b.bar();           // manually delegate
    }

Now let's say A accesses its superclass's private variables in order to do something. The equivalent* is:

    A.prototype.foo = function() {
      return this._b._privateVar * 2;     // obviously bad, don't do that!
    }
    

You wouldn't access the private variables of an object you compose; it's obviously bad form. Don't do it when you inherit, either.

Now let's talk overriding the superclass's methods. There are several different ways you could do that. The equivalents* are:

    // Replace superclass method
    A.prototype.bar = function() {
      return "my own thing";            // obviously fine
    }
    
    // Replace superclass method and access superclass state directly
    A.prototype.bar = function() {
      return this._b._privateVar * 2;   // obviously bad, don't do that!
    }
    
    // Extend superclass method
    A.prototype.bar = function() {
      var result = this._b.bar();       // equivalent* to calling superclass method
      return result * 2;                // perfectly okay
    }

    // Extend superclass method and access superclass state directly
    A.prototype.bar = function() {
      var result = this._b.bar();       // equivalent* to calling superclass method
      return result * this._b._privateVar;   // obviously bad, don't do that!
    }
    

Don't access the private variables of your superclass (or objects you compose) and you'll be fine. Sure, you'll be in trouble if the superclass changes the semantics of the parent method, but that's true of all functions everywhere. If the semantics of a function you're using changes, your code probably just broke. It doesn't matter if the function is defined in a superclass or not.

The one thing that's unique to inheritance is the idea of semi-private ("protected") methods that are only visible to subclasses. I agree that they're something to be used sparingly, but they're no different than any other superclass method in how they should be used and overridden. It's a moot point, though, because JS doesn't have them.

*Not exactly equivalent, but close enough for these examples.