I think that's the first time I've seen concrete ARC/L2ARC ratio recommendations! Thanks!!!
I assure you that it is anything but concrete. Proper sizing of ARC/L2ARC is an art that is dependent on your workload, desired performance improvement, etc.
The game you're playing is that you're trading off fast things for each other. The L2ARC requires a pointer record to be stored in the ARC that indicates what is stored in the L2ARC. This used to be 180 bytes per record years ago but was reduced to 70 in a rewrite. This doesn't really mean that ZFS can handle "twice the L2ARC" though. The important quality that many n00bs (including some portraying themselves as ZFS experts on Reddit, etc) miss is that the quality of L2ARC caching that ZFS is capable of is highly dependent on the workload and the ability of the ARC to properly classify buckets of traffic into MFU and MRU. If you read fifty blocks from pool but your ARC is so small that most of these are evicted before a second read occurs, you don't get a good idea of which of these blocks would have been good L2ARC candidates, and just a random set of them end up written out to L2ARC.
What you really need is sufficient ARC to hold a nice percentage of your working set of blocks. And then you can look to see what percentage of that would benefit from L2ARC. Once you can tell the blocks that are read five times from the blocks that are only read twice, your ARC works better and makes better classification choices.
So people get all bent out of shape about the ARC:L2ARC ratio here, but from my perspective, the interesting ratio is that of the working set (the blocks you access semi-frequently) to the size of the ARC and L2ARC. This is too complex for most people to wrap their heads around, especially if new to ZFS. That's the value of some rule of thumb guidance.
I've often been criticized for my strong recommendations to avoid L2ARC below 64GB of RAM, and certainly there are going to be situations where the working set is small enough that an L2ARC could be useful down there at 32GB or even 16-24GB. But that's not the usual situation. Usually by the time you get up to 64GB of RAM, unless you have a massive pool with massive working set size, you're likely to be seeing at least some traffic in the ARC as reasonably good candidates for L2ARC eviction. Once you get to this bootstrap point, you then have some helpful numbers to guide you beyond that.
Once you've got that handle on things, it becomes much easier to set goals. For some time, I had an iSCSI target host on which I wanted most reads to be satisfied from L2ARC. It's kinda freaky to sit there in "zpool iostat 1" and see no pool reads for long stretches, and just a steady stream of write traffic. The L2ARC on that system was "probably" too large, but it offered maximum performance for both reads and writes. That was 256GB RAM with 1TB L2ARC on a 14TB (~7TB usable) pool, just to give you an idea.