So, you must have tried his code too, getting to a conclusion that it
is useless if you care about speed...  I tried it too (s1=subsets,
s2=subs, s3=subs2, s4=combos, s5=subset):

| > (define a '(a b c d e f g h i j k l m n o p q r s t u v w x y z))
| > (time (begin (s1 a 8) #f))
| cpu time: 25520 real time: 25485 gc time: 7580
| > (time (begin (s2 a 8) #f))
| cpu time: 10730 real time: 10715 gc time: 5640
| > (time (begin (s3 a 8) #f))
| cpu time: 7290 real time: 7245 gc time: 2610
| > (time (begin (s4 a 8) #f))
| cpu time: 13720 real time: 13710 gc time: 500
| > (time (begin (s5 a 8) #f))
| cpu time: 66130 real time: 66334 gc time: 41470

and it definitely looks like his solution beats the hell out of the
rest in a worst running time competition...  (And again, wins at
clarity -- the lines in each solution (all re-indented in the same
style) are s1=9, s2=14, s3=18, s4=12, and s5=8 lines.)

The thing is that once you realize that the solution is functional,
you can simply memoize it, and get:

| > (time (begin (s6 a 8) #f))
| cpu time: 5440 real time: 5454 gc time: 1700

clearly beating the rest...

[I always wonder why does everyone teach dynamic programming with
stupid matrices where memoization lets you keep your program exactly
the same and getting the same benefits...]