The stress tool doesn't have a wide row scenario so it's hard to simulate out of the box
Agreed, and that's definitively lacking. I believe there is a few knobs that allow to do wideish rows, but that's probably not very realistic.
I think LCS only ever makes sense on SSD
since LCS is for wide row or heavy updates
I'm not sure I agree. Maybe there is some truth to it in our current implementation, but that would then be more of a quirk of the implementation that the goal. Typically, I'm not really sure why only wide rows would benefit it. There is certainly nothing in theory that makes it so. As for "it's for heavy updates only", I think that LCS has a number of nice properties (like avoiding huge files that require half of you disk in free space) that are nice even if you have a moderate to low update rate (and in that case you can definitively afford LCS on HDD). More concretely, I'm pretty sure we have tons on users on LCS on HDD.
Anyway, all this to say that I don't necessary agree on optimizing LCS for heavy writes + wide rows + SSD if that's done at the expense of all other type of workload (and I'm not saying that's what this patch is doing, just that discarding other type of workload as unimportant is not ok imo).
LCS has a 5MB limit you still end up with a 10MB sstable with a single row
If having 10MB sstables being split due to row too wide is a problem, then you should either not use LCS or pick a 10MB limit for LCS, not 5MB.
Anyway, I'm not vetoing this or anything like this. Just trying to get a better understanding of why this is a good thing to do in general.