I'm pretty conservative about increasing the standard dust limit in any way. This would convert a higher percentage of LN channels capacity into dust, which is coming with a lowering of funds safety [0]. Of course, we can adjust the LN security model around dust handling to mitigate the safety risk in case of adversarial settings, but ultimately the standard dust limit creates a "hard" bound, and as such it introduces a trust vector in the reliability of your peer to not goes
onchain with a commitment heavily-loaded with dust-HTLC you own.
LN node operators might be willingly to compensate this "dust" trust vector by relying on side-trust model, such as PKI to authenticate their peers or API tokens (LSATs, PoW tokens), probably not free from consequences for the "openness" of the LN topology...
Further, I think any authoritative setting of the dust limit presents the risk of becoming ill-adjusted w.r.t to market realities after a few months or years, and would need periodic reevaluations. Those reevaluations, if not automated, would become a vector of endless dramas and bikeshedding as the L2s ecosystems grow bigger...
Note, this would also constrain the design space of newer fee schemes. Such as negotiated-with-mining-pool and discounted consolidation during low feerate periods deployed by such producers of low-value outputs.
`
Moreover as an operational point, if we proceed to such an increase on the base-layer, e.g to 20 sat/vb, we're going to severely damage the propagation of any LN transaction, where a commitment transaction is built with less than 20 sat/vb outputs. Of course, core's policy deployment on the base layer is gradual, but we should first give a time window for the LN ecosystem to upgrade and as of today we're still devoid of the mechanism to do it cleanly and asynchronously (e.g dynamic upgrade or quiescence protocol [1]).
That said, as raised by other commentators, I don't deny we have a long-term tension between L2 nodes and full-nodes operators about the UTXO set growth, but for now I would rather solve this with smarter engineering such as utreexo on the base-layer side or multi-party shared-utxo or compressed colored coins/authentication smart contracts (e.g opentimestamp's merkle tree in OP_RETURN) on the upper layers rather than altering the current equilibrium.
I think the status quo is good enough for now, and I believe we would be better off to learn from another development cycle before tweaking the dust limit in any sense.
Antoine