for which specific code-signing applications and environments (router firmware updates, user OS updates, cloud embedded device firmware update verification) are these parameter sets most practical?
Well, LMS is best suited if:
You need good security (e.g. postquantum); LMS makes the assumption that SHA-256 is strong (alternatively SHAKE-256 for some other parameter sets) - it makes no other assumptions.
You don't mind largish signatures (well, large compared to RSA or ECC signatures - they compare quite nicely to other postquantum signature algorithms)
You can control the signing process; specifically, you can ensure that you don't accidentally reuse state.
The last criteria is the critical one for most applications; it's difficult to see how it can be used on (say) a PC, because we're likely to store state on disk, and if that disk is backed-up and restored, we've lost track of the state.
On the other hand, if you have a centralized signer, and you can ensure that state is managed properly (ideally on an HSM), then it works.
The key lifetime in particular?
Every LMS key has a bound on the number of signatures it can generate; this is what we are referring to as "key lifetime"; obviously, if you generate one signature per update, you want to set this bound higher than the number of updates you'll ever generate. I don't personally see it as a major issue, because we can easily set that limit to be so huge (e.g. $2^{60}$) that we'll never hit it. This does increase the size of the signatures, but not drastically.
