The 12 hour vs 2 hour thing is to allow for a degree of normalization, similarly to how it's unclear about what's being considered when 1 applicant spends 3 hours on a LC medium and another spends 30 minutes. Spending an extreme amount of time on take-homes confounds simple pride with someone who's otherwise a bad fit skills-wise but can eventually make up for it with an input of time, something that might not be appreciated after an offer is accepted. Too often companies will refuse to speak further with candidates if even 1 out of 20 test scenarios are not covered just because someone else chose to spend their entire weekend on the problem -- they'll be the same ones complaining about a dev shortage, no doubt.
This goes back to the days where job ads would request N years of X experience. The big takeaway from the last ~10 years is that this type of requirement is unnecessary. As an engineer who knows the fundamentals, it's relatively straightforward to pick up a new tech stack.
I wouldn't want to pass on someone who spent the last 5 years working in C because we have a java stack.
For take-homes, I don't think the candidate spending 12 hours on something that should take 2 is necessarily a negative signal - but it's also something that should be considered. If the candidate spent 12 hours ensuring the solution was perfect, then it's probable that they are just thorough - which is a good thing more often than not. You do end up in a quirky situation of judging candidates by how much time they are willing to dedicate to your take-home interview though.
Anecdotally, for the few take-homes that I've done - I've always gone a bit overboard out of pride. Granted, this is also how I approach a lot of coding tasks.. so I guess you get what you test for?