FFMpeg Encoding and Core Usage
BTW, this question might be better on stackoverflow, or maybe unix.stackexchange, or maybe serverfault.  This site is I think less focused on questions that don't involve decisions based on creative merit or at least perceptual video / audio quality.  However, I'm all about the tech details, so I'll answer.

FFmpeg uses multi-threading by default, so you prob. don't need -threads 0.  If your encode is bottlenecked on a single-threaded filter or decoder, you'll see full load on one core, and light load on many other cores.

One thing you can do is check mediainfo of your output video.  x264 leaves its settings in an ASCII string in the h.264 header.  So either strings -n20 or mediainfo to get:

...
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.051
Stream size                              : 455 MiB (89%)
Writing library                          : x264 core 146 r2538+1 d48ec67
Encoding settings                        : cabac=1 / ref=6 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.70:0.10 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=4 / lookahead_threads=1 / sliced_threads=0 / nr=50 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=22.5 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=3:0.60
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709


Note the "threads=4" in there.  I think I manually set that on my quad core i5 2500k, instead of letting x264 use the default CPUs * 1.5, since I had a CPU-intensive filters (hqdn3d and lanczos-downscale) running.

Anyway, libx264 with a preset like slower should have no trouble keeping a lot of cores busy.  There are some parts of encoding that are inherently serial (e.g. the CABAC encode of the final bitstream), so a high-bitrate video that doesn't spend a lot of CPU-time refining references (high subme) to multiple frames (high ref) might show a load pattern like yours (one thread using 100% CPU, others not).

I'm not 100% sure about faster presets being less parallel, but I know CABAC is serial.

To get massively parallel, libx264 could use a boatload of RAM to keep frames around, and keep doing lookahead for 2 or more GOPs, and encode those independently.  It doesn't have an option to operate that way, though.

One way to make use of MANY cores is to run multiple separate encodes in parallel, instead of just a series of single encode using all cores.  This only works if you have multiple input files that you want encoded separately.  You're trading off threading overhead vs. more memory capacity and bandwidth (with an impact on caching, unless this is on a multi-socket system with separate L3 and DRAM for each cluster of CPUs, and you have the processes pinned to cores so one encode is using the cores in one socket, and the other the other).