Nothing but when you nest them a whole bunch they are far harder to read and understand that if/else.

I frankly find it hard to imagine an expression form of if...else that's more readable than either the JS or Scheme versions of the code.

In fact, I believe the problem with the JS example's readability is the formatting. Here's how I'd format the same code, and I find this quite readable:

    function deriv(exp, variable) {
        return is_number(exp)
            ? 0
            : is_variable(exp)
            ? is_same_variable(exp, variable) 
                ? 1 
                : 0
            : is_sum(exp)
            ? make_sum(
                deriv(addend(exp), variable), 
                deriv(augend(exp), variable)
            )
            : is_product(exp)
            ? make_sum(
                make_product(multiplier(exp), deriv(multiplicand(exp), variable)), 
                make_product(deriv(multiplier(exp), variable), multiplicand(exp))
            )
            : error(exp, "unknown expression type -- deriv");
    }

Scala-style if expressions would be significatly more readable IMO (particularly if you also had the feature of allowing a block to be used as an expression).

    function deriv(exp, variable) {
        return if(is_number(exp))
              0
            else if(is_variable(exp))
              if(is_same_variable(exp, variable))
                1 
              else 
                0
            else if(is_sum(exp))
              make_sum(
               deriv(addend(exp), variable), 
               deriv(augend(exp), variable)
              )
            else if(is_product(exp))
              make_sum(
               make_product(multiplier(exp), deriv(multiplicand(exp), variable)), 
               make_product(deriv(multiplier(exp), variable), multiplicand(exp))
            )
            else error(exp, "unknown expression type -- deriv");
    }

Just for looksies.

    function deriv(exp,v){
      //v = variable;
      if(is_number(exp) ){ return 0 }
      if(is_variable(exp){ return is_same_variable(exp,v) * 1 }
      if(is_sum(exp)){ 
         a = deriv(addend(exp),v);
         return make_sum(a,a)
      }
      if(is_product(exp)){
         m = multiplier(exp);
         c = multiplicand(exp); 
         a = make_product(m,deriv(c,v));
         b = make_product(deriv(m,v),c));
         return make_sum(a,b)
      }
      return error(exp, "unknown expression type -- deriv");
    }

I'd possibly make it even more syntactically simple by removing the braces for one-line if statements. I know this can be a bit controversial, but for cases like this where the block consists only of a return statement, and where that statement fits on a single line (and where you have a formatter and a linter that will prevent you from writing indentation that doesn't match the semantics), it's very useful for removing visual clutter.

That said, this is pretty much how I'd write it, and seems a lot simpler than the heavily nested ternary (and I say that as a fan of nested ternaries!)

The 0 and 1 are completely unnecessary though in some of these.

Example

is_same_variable(exp, variable) ? 1 : 0

If is_same_variable returns a truthy value then return 1 else 0.

We can remove that and it will still follow the same while also being more readable

It’s calculating the derivative. 0 and 1 aren’t used for their truthiness, but as values. d/dx x becomes 1 and d/dx y becomes 0 (the two cases, same variable and different variable).

JavaScript will coerc the types. 1+1 and true+true both = 2

So you've gone from "nested ternary is hard to read" to "This is an introductory text, let's mix arithmetic with numbers and booleans by using true and false for 1 and 0"? That's a remarkable turn in just a few comments toward the side of obfuscation.

I'm not trying to change the code, I'm only formatting it.

(is(((it any) harder than) this?))

You'd be surprised at how readable Lisp is for people who actually learn it instead of just saying "look, weird language ha-ha!"

Yes, since Lisp isn't hard to read.