Here's a summary a bit longer than the two sentences provided by chalst. (Yes, there's an abstract, but the abstract gives very little information about the actual substance of the paper.)

Shortcomings of SICP/Scheme alleged by others: SICP's content too difficult for non-MIT students; Scheme too different from the mainstream; early CS courses (even at MIT) should concentrate on the basics. Also, a pointer to Wadler's 1987 critique of Scheme, proposing that a Miranda-like language (nowadays he'd likely propose Haskell) would have been a better foundation for SICP. You can find that at http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.p....

What the authors think an introductory programming course in a CS curriculum should look like: Focus on principles rather than industrial requirements or particular languages. Specifically, teach students to analyse problem descriptions, think about examples before writing code, and structure their code and data structures to match the problem. Give more priority to data and less to code than in traditional curricula.

What the authors think about a suitable language for this purpose: Functional rather than OO, because functional languages are simpler and neater, and because their computational model grows naturally out of the mathematics students know from school. (Then teach a more standard OO language in a second course, with more of an eye towards practical use in industry.) Specifically, choose Scheme because its syntax and semantics are simple, it's safe (no crashes, memory corruptions, etc.), and there isn't an explicit type system to get in the way. Use carefully defined subsets of Scheme to make things even simpler and to enable the implementation to handle errors more helpfully. Provide a simple programming environment that can edit and execute programs, and illustrate concepts like scope and lambda-calculus-style reductions.

Critique of SICP: Not enough about how programmers decide what procedures to decompose their code into, when and how to introduce layers of abstraction, etc. In general, not enough about ... how to design programs. SICP's examples often assume too much domain knowledge in mathematics and engineering.

Features of their own book motivated by the above: It talks explicitly about how programs should be designed. It decomposes Scheme into nested subsets, teaching the simpler ones first. Its examples don't involve, let alone focus on, extraneous domain knowledge. Every chapter has a section on designing a particular kind of function. Explicit design knowledge is formalized in recipes.

They draw particular attention to a distinction they've introduced between "structural" recursion (where your code has a recursive structure that simply matches the recursive definition of your data types; for instance, insertion-sorting a linked list, which sorts the tail and then inserts the head) and "generative" recursion (where your code has a recursive structure for other reasons, and makes its own new data to apply the recursive calls to; for instance, quicksort, which builds two new lists and sorts each of them). They suggest that drawing this distinction, and then focusing on structural recursion, makes their material easier to follow and prepares the ground more naturally for learning OO languages later (where, as with structural recursion, program structure is somewhat derived from data structure).

They introduce the notion of iterative refinement as a design tool for both code and data.

Experience with HtDP: They've compared it with college courses based on C++, and found it much better. They've compared it with unspecified high-school AP courses, and informally found it better. (There's no comparison to SICP.)