Optional, though the language and standard library are kind of designed around it. So I'd say Nim can be used without the GC, but is optimized with the idea that you'll use the GC by default, with escape hatches for manual allocation when you need the power for performance or efficiency, e.g. manually managing big blocks of memory for tight loops.
Contrast to a language like Zig, which has a standard library and syntax built around the idea of manual allocators and what not, but is missing the "ease of use" of GC. Personally, I agree with GP, and like Nim's compromise of GC with a "I know better, let me do it manually" syntax, but there are domains where you want a language like Zig.
Correct. I'd add that with ARC (or ORC even), there's little reason to do manual memory management (alloc/free), even for embedded systems. ARC is an automatic memory management system based on reference counting, but there's no "runtime". It actually injects alloc and free calls at compile-time based on static analysis.
ORC adds runtime GC only for cycles, and will be the default in Nim 2.0.
Contrast to a language like Zig, which has a standard library and syntax built around the idea of manual allocators and what not, but is missing the "ease of use" of GC. Personally, I agree with GP, and like Nim's compromise of GC with a "I know better, let me do it manually" syntax, but there are domains where you want a language like Zig.