Domain specificity can be mitigated by matching the interview problem(s) with the tech stack that's being hired for. Doing a refactoring of some basic Java code that's not going crazy with annotation processing would be quite reasonable for a job ad seeking to hire someone to do Java development; the same problem can be replicated in Python, JavaScript, etc. to accommodate different skill sets. I wouldn't expect this style of an interview to determine whether one understands the specific gotchas of Django Models if the company is seeking an average developer to do average work for average pay.

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.