I think the chapter has a good overview of other language comparisons, but the final table should probably include a few others like D and OCaml (and if you're including those you should also include Lisp via SBCL and Racket..) and stress that for Nim the GC is not only "Yes, multiple" but also optional/bypassable, which is of great importance to C/C++ people. Maybe an appendix for more details / more languages? Rust and D probably deserve more details but anything with a forced GC, probably not... So I second the opinion that perhaps a little too much time is spent comparing with Python, but you're in a much better position to tell how many newcomers to Nim are actually dropping Python just about completely for it. (For me, even though I'm still in the playing stage with Nim, I can already say with certainty Nim won't replace the things I use Python most for already, especially since I'm committed to a preference for dynamic typing over static, and I would argue the sentence on page 17 that "Replacing Python is especially easy because its syntax is so similar to Nim's" is false for any non-trivial Python code...)
The biggest dimensions for me when first evaluating a new language that I might want to learn more about someday are typing (dynamic, untyped, or static, and if static whether that's of the Haskell variety or more mildly anti-certain-class-of-errors-driven plus performance-driven like most other things) and garbage collection (none, forced, or optional). That info helps me immediately bucket what sorts of applications this new language could help me take on in a better way than other languages I know. With Rust, watching it develop I didn't think too highly of their decision to remove the @ sigil (that is, remove the GC from the core language). That's what ultimately made me think of Rust only as something I'll ever try to learn and use if I come across the narrow (in my interests) problem domain of "I absolutely require a Safe program but for some reason I can't use a GC language."
I think your first 12 pages do a pretty good job at highlighting some of the hooks that originally put Nimrod on my watch list whenever ago, though personally I'd put the style insensitivity thing last (and it doesn't cover things like omitting parens for single-arg or no-arg functions but you mix that particular style choice around throughout the chapter). Those hooks, including some you don't really cover yet, are speed (like, at or even sometimes beating C-level speed), all three of optional, tunable, implementation-detail-swappable garbage collector with access to malloc/free or even just embedding C code directly like you might embed ASM code directly in C code, inferred static typing to minimize ceremony, the huge list of pragmas to tell the compiler -- which humbly admits it tries its best but is not all-knowing -- about useful things for performance or other reasons, user-defined compiler demands (not "hints", as it's not optional) to make optimizations via term-rewriting macros, style choices (but sadly no Lisp-like dashes in function names), and an awareness of and support for many higher level language features enjoyed by other languages. No forced main() and whitespace indentation make it immediately comparable to Python on the surface which is a nice bonus (for those that like Python anyway). Taking all these things together, there isn't really a comparable language, or at least not one that's on very many people's radar. I think the only language worth mentioning (or not, per strategy) as one that might surprisingly come up from behind in n years and eat Nim's potential big lunch by then is Pony.
Another nitpick, in the section on functional programming, why use var instead of let? The immutability story is just as important as first class functions... And you're missing the item (->) in the list of things the modules were imported for...