The recommendation for 2048-bit RSA is also a headscratcher. I get why you'd want to prefer ECC, but if you have to use RSA for some reason is there any scenario where you wouldn't also want 4096-bit keys?
Mozilla's TLS and SSH recommendations are pretty solid though.
https://latacora.micro.blog/2018/04/03/cryptographic-right-a... is an alternate, arguably better, source of information.
If you have the advantage of only working with newer hardware, this is true. But it's not immediately obvious whether or not your CPU supports 256-bit AES-NI without e.g. benchmarking OpenSSL.
The point isn't "AES-256 almost never supports AES-NI" (although that used to be true). It's that naively saying "biggest rock is best rock" doesn't always hold true.
> If you have to use RSA for some reason is there any scenario where you wouldn't also want 4096-bit keys?
You're sacrificing performance for a hypothetical security gain that probably won't matter. If 2048-bit RSA gets implicated by some new attack, it's more likely that 256-bit ECC will save you than 4096-bit RSA.
> https://latacora.micro.blog/2018/04/03/cryptographic-right-a... is an alternate, arguably better, source of information.
When people are asking for a guide on Cryptographic Right Answers, I always point people to that page.
The questions I wanted to address are about key size. And the point I wanted to stress was, "There are usually other factors that are far more important to consider than just the size of the key."
If I see a system that uses RSA to encrypt, I care more about it not using textbook RSA or poorly-implemented PKCS#1v1.5 padding than I do about 2048-bit vs 4096-bit keys.
This was something I had observed in practice over the years (i.e. several orders of magnitude performance difference between AES-128 and AES-256 from my PHP implementations), and "your CPU only supports AES-NI for 128-bit keys" was the explanation I was given at the time. I haven't observed this recently, and I'm on newer hardware, so the explanation made sense.
In attempting to identify which CPUs were affected by this limitation, I've discovered that I was grossly misinformed about this. I'm going to update the article to redact this, ASAP.
UPDATE: Redaction applied.
For the time being, 3072b seems to be "good enough" if you want more than 2048b. It's all you need for official Top Secret stuff (per IAD-NSA), as well as BSI and ECRYPT-CSA recommendation for the next few years:
There's nothing "wrong" with it per se, it's just that it's probably not strictly necessary. Why take the (potential?) performance hit by going to 4096 if it doesn't really get you anything practical?
Most people don't seem to care about whether they're using 128- or 256-bit AES, but when it gets to RSA there seems to be a bigger debate between 2048 or 4096 (with 3072 hardly being mentioned).
I absolutely am in favor of just using libsodium box/secretbox instead of having to understand this sort of nuance.
> Who is a laddered recommendation of different signing algorithms really helping?
People who ask me nitpicky questions about whether or not they should opt for 3072-bit RSA keys instead of 2048-bit RSA keys. The main purpose of the post was the first half (the "it doesn't matter" point).
This could happen if they're relaxing their recommendations to double down on post-quantum cryptography.
This could happen if they had a mathematical breakthrough that invalidated all ECDLP security estimates.
I'll never know which it is. The pragmatic thing is to research PQCrypto and make sure the next generation of asymmetric primitives are as good as they can be.
CBC is not an option that you should be considering in 2019.
TLS's AES-CBC is MTE not ETM, and that distinction matters . You shouldn't use CBC mode in SSL/TLS. (You also shouldn't be supporting SSL; only TLS.)
But an application-layer AE construction  as described in the article is fine.
It doesn't really matter which you use under most threat models.
AES-128 gets you guaranteed AES-NI on virtually all processors sold in the past decade. AES-256 gets you better assurance against quantum attackers, should they ever become a real threat.
You can side-step both of these by just using a ChaPoly ciphersuite which is constant-time and fast on all platforms, without hardware acceleration. (If you ecide to just use libsodium's box/secretbox, as Thomas said in another comment, you're doing this side-step... which is thematically appropriate for a cipher named after a Latin dance).