There can be a relatively easy calculation based on the number of transaction bytes requirde to open and close channels, the number of channels that thereby can be opened, given some given an average HTLC duration, it's in the LN whitepaper, in fact, and I think they essentially say that for LN to replace all known payment rails in the world, Bitcoin blocks have to be 138mb in size. But again, if the channels are longer lived, their imprint on the chain is reduced proportionally.

As I understand it, several featurse under discussion to be added can drastically reduce the data load. Covenants is one I hear many times.

Bitcoin blocks at 138mb would be practical in about 15 years time if storage capacity and latency continues to improve at even 50% of current rates.

The block size issue will always be about whether you can defer upgrading your monitor and instead get a bigger hard drive to run your node. To use rough comparisons. Bitcoiners will not, and should not allow an increase in block size until, at minimum, LN is filling half the blocks on average. That's not gonna happen for another few years yet.

It has been tested to be around 30 - 100 TPS across implementations on general hardware. https://bottlepay.com/blog/bitcoin-lightning-node-performance/

Renè Pickhardt had in the past intensive studies about that aspect and many more. Here is one of his short videos explaining the TPS of LN

Max number of open HTLCs is 483. You can probably push more payments per second through a channel between direct peers, but when you consider multihop payments and the need for liquidity and all of that, i think ~500 is a reasonable bound for doing napkin math