I thought it had a noble goal but it fell far short of the mark. I see at least two big problems with it.
First, their notation is a definite improvement on traditional notation in that it can in principle be translated into s-expressions and thus at least potentially avoids the ambiguity of traditional notation. However, it still looks like traditional notation and so it still inherits many of the problems of that notation, not least of which is that parsing it is really hard, even for humans. The fact that all of the formulas in the on-line version of the book are rendered as gifs is symptomatic of this. If you want to actually follow the program of the book and run the code that corresponds to the formulas, you have to render the formulas into Scheme by hand. Well, OK, you could just use the on-line code, but that's cheating. The whole point (or at least a big part of the point) of the notation was supposed to be that mapping it onto s-expressions was supposed to be simple, and it's not.
Second, and much more seriously, they don't actually follow their own rules. Look at equation 1.1. I can't reproduce it here because it's a gif, but I can reproduce a reasonable facsimile of some of the following explanatory text, which goes:
... where F[gamma] is a function of time ...
The problem is that F[anything] is not the notation for a function. Functions are denoted simply by letters, and the values of functions are denoted by juxtaposing the name of the function with a list of arguments delimited by parens (which overloads the meaning of parens because they also denote up-tuples, but we'll let that slide). So F is a function, but F[gamma] is not, it is ... what? A function juxtaposed with a 1-element down-tuple?
If you look carefully, you will notice a footnote that kinda sorta explains this:
"Traditionally, square brackets are put around functional arguments. In this case, the square brackets remind us that the value of may depend on the function in complicated ways, such as through its derivatives."
So they very carefully describe a precise notation, and then in the very first equation in the book they abandon that notation and use a completely different notation that indicates that something may depend on something else in unspecified but potentially complicated ways. Worse, it now adds even more ambiguity to the notation, because now both parens and square brackets are ambiguous with respect to whether they are denoting function arguments or up/down tuples. So we've already run off the rails before we've even begun.
I give it an A for effort, a D- for execution.