I like it because it makes it easier for me to see the big picture. The forest and the mountain. It doesn't over-emphasize the bark on the trees; it doesn't drag on and make me scroll & jump through a maze of boring minute detail. At the same time, it doesn't actually bury and hide whatever detail there is; it's all there for when you need it. Whitney also generally simplifies things a lot and avoids tedious contortions others would make for portability or some theoretical conception of maintainability, readability, or vague "best practices". It's very straightforward and -- once you get past the Whitney vocabulary and general style -- there are no mountains of abstractions and layers you need to grok before you can work on the code.
The biggest problem is that after getting used to that style, "normal" code starts to feel like kindergarten books with very simple sentences written in horse sized capital letters, a handful per page. Except that those letters are not used to write a short children's story, but a complex labyrinthine machine, and the over-emphasis on minute detail just obscures the complexity and you end up with cross cutting concerns spread over thousands of lines of code and many many files. It might look clean and readable on the surface, yet: there be dragons. And nobody wants to tame those dragons because there's so much code. And then I find myself sighing and asking: why on earth do we need an entire page for what would really amount to a line of code if we didn't insist on spelling everything out like it's babby's third program after hello world? It's just tedious.
Whitney certainly writes his own sort of dragons, but it's easier to keep them all in your head. For example, the b compiler won't work out of the box on multiple platforms. I'm fairly confident I could port it without much effort, as long as the platform meets some basic requirements.