Most of the commenters on the blog talk about the mining/thermodynamics part, but I naturally find the lightning part the most fun. It's a little rage bait-y and hyperbolic, but that's what makes it a fun read - all the assumptions stretched thin enough that you can try and poke holes in them. Impressively, it was written in 2020 back when most of us were in our bitcoin diapers.
The first "hype buster" is the only criticism that's not debatable.
Lightning is almost certainly not going to scale for micropayments in the long term. Lightning fees are not disconnected from the fee market for blockspace, they are derivative of them. The reason micropayments work natively on Lightning right now is because fees for blockspace are so low right now; when fees for blockspace go up that will drag fees up for Lightning payments as well. It is not economically rational to be routing payments for profit on Lightning if the eventually necessary on chain operations immediately eat up everything you have earned off chain. Fees on Lightning will increase to compensate for this. And that is just the first issue with micropayments on Lightning.
Lightning network fees are always going to be derivative of onchain fees. Whether they 1st or nth derivative, committed/spliced/closed in another layer, they are derivative.
Another issue is the value of payments. Every Lightning payment, regardless of the value being routed (and remember, part of the fees on Lightning are % based, so higher value = higher revenue for routing), costs the same amount of data. It costs the same amount of CPU operations, of electricity expended, however you want to conceptualize it. Pushed extremely to the margins with the ability to profitably perform ‘x’ computational operations in a time period, won’t you always prefer higher value transactions to maximize revenue?
In retrospect at least, this is a silly point (people were probably thinking of lightning nodes like ASICs back then). The marginal compute cost of a forward is basically zero. Even that weren't true, no one makes decisions to not foward htlcs based on compute resources because things like liquidity and in-flight HTLCs are much more scarce/expensive.
And yet another issue, are the problems with too many unresolved HTLCs live in one channel at a time opening nodes up to attacks unless they limit the amount of unresolved HTLCs they will engage in at one time. This is a further introduction of scarcity in terms of opportunity cost with income. Why would I route your 1/10th of a penny microtransaction which might get me a 1/10th of a penny when I can route this other guy’s 10$ payment and earn 15 cents?
HTLC slots and liquidity are scarce which will have consequences;
min-htlc floors will rise if HTLC slots become too scarce. But, this is kind of like saying economy cars won't exist because luxury cars make more money per unit. If people can make money doing something, they generally do it. So long as small lightning payments are profitable (even indirectly like with negative inbound fees), compute and htlc limits included, some node will route them.Limits and fixed costs are hints that, in isolation, HTLCs won't be profitable below a certain size, but it's naive to think cherry-picked constraints account for everything that's likely to happen in a global, decentralized, networked market. It's naive to assume small HTLCs will be profitable to route, but it's naive to assume they certainly won't be (even if being pessimistic makes you feel smart).
These kinds of false expectations are ultimately at the root of what lead to the big block divide and the split off by Bcash. A long period played out of completely unreasonable expectations being set, and when the time finally came that they were shattered a large swath of people would or could not accept that. Now I don’t think similar expectations being shattered now is going to lead to some doomsday fork or fracture (though it could), but micropayments are very important. They are in general a mechanism to shift the internet away from KYCed tagged and tracked access to services and infrastructure online. But imagine if as micropayments start to embed themselves into applications, they do so in a naive and short sighted way. They assume that Lightning will be a suitable micropayments layer natively. That is potentially a large amount of broken infrastructure when reality kicks in. How does that play out in the war of network effects? Adapt to reality vs. force reality to adapt.
The weird thing about protocols is that supporting one "natively" means you're largely agnostic to how they manifest externally. You will interop with whatever is external regardless - granted you don't assume how the protocol manifests externally or assume that the protocol can't be replaced by something wildly different with fewer capabilities.
On LN fees being derivative of on-chain fees
On whether micropayments can be profitable
min-htlcstuff too well, but I assume it's related to channel congestion of some kind. Again, it seems like that could be resolved by smarter route-finding algorithms and a dense enough network of connections.