Generally LN nodes want the transaction to confirm within n blocks but they don’t want to pay more fees than necessary. Confirming ASAP is generally not needed, unless deadlines are getting close.
But I think you make a good point that there is probably a mismatch here between the fee estimator’s intended use and what LN nodes do. If the estimator says a certain fee rate should get the transaction confirmed within n blocks and then confirmation takes n+1 blocks, that’s probably not considered a big deal from the estimator’s point of view. But for LN nodes there’s a huge (and expensive) difference.
Presumably this is why eclair switches to exponential bumping once the deadline gets close, and why LDK uses exponential bumping whenever the estimator does not return an increased fee rate.
Improving Bitcoin Core’s estimator is great and should decrease the number of LN node operators that rely on third-party estimators such as mempool.space or Blockstream.
But fundamentally, estimators are still estimators and cannot guarantee that transactions confirm before deadlines, especially when directed attacks are in play (pinning, censorship, etc.). In such situations a naive budget-based fee bumping strategy is much more reliable.