The problem with reading stuff on the Internet is that it's usually got no useful rationale (if you're lucky), doesn't apply to your situation, or is downright plain-and-simple wrong (by far the most common).
If your request processing is entirely CPU-bound within the fpm worker, then yes, having any more than one process per core isn't going to improve throughput. However, that is an incredibly rare scenario -- typically your PHP script is hitting the DB, or reading stuff off the filesystem, or making external connections to fetch other data, or whatever. All of that is CPU time that, if you've only got one fpm worker per core, is going to be wasted.
What is the correct configuration for your environment is a mix of "know your app" and experimentation. I'd try with probably two fpm workers on a single core, and see what happens under load (real load, not ab load). If the CPU is completely pegged, then you're probably doing more CPU work than can be handled and you should dial it back a bit (or just get more CPU). If you're maxing out on throughput but the CPU is still fairly idle, then you can ramp up the number of workers until the CPU is close to maxed out.
Of course, this assumes that there isn't a lot of other stuff going on on the machine that needs CPU time itself. You've got to give nginx some CPU time, and if you've got a database or anything on there it'll need a look-in too, but happily enough that tends to sort itself out as you watch the CPU go up with worker count.