As for on-chain size increases, those need to be preceded by study into off-setting the additional processing burden higher blockweight limits represent. Segwit is somewhat of an example; allowing signature hashing to scale linearly mitigated (but did not offset) the increase to a 4MB block limit.
Have there been any noteworthy studies on the potential effects of bigger blocks since the IC3 and Bitfury studies? I suppose that data is a few years old now.
Not aware of any, but I would look more to the developers implementing features like MAST or Schnorr for that type of information, the stuff that hits the press is usually self-promoting (why take it to the press otherwise). I think 1 MAST implementation exists (but is controversial), and no Schnorr implementations exist yet. Benchmarking to gauge the extent that MAST could permit larger blocks doesn't exist, AFAIK.
My biggest concern at this point isn't the marginal nodes and miners that couldn't keep up with the network. I'm much more concerned about the propensity for any hard fork to cause a permanent split with multiple resulting networks. Segwit was a one-shot deal; there's only so much you can do by discounting witness data. We can further optimize transaction size, but eventually, the notion of a hard fork block size increase will rear its head again.
I'm not sure about Segwit being a one-shot, it's possible that future soft forks could be designed to increase the max blockweight even further. I would certainly hope it can be done, as it's the least disruptive way to do so.
This doesn't have to mean hard-forked blockweight changes will be difficult, though. I think once the case for that is genuinely compelling, then it will happen. Up till now, that case has been rejected by most Bitcoiners. But people will change their minds about it as improvements to block processing are tested and proven on the live network.