I think this is a very common situation, sadly resulting from both sides of the hiring equation - candidates and employers - making mistakes and covering them.
Other answers here assume some additional competence in the companies' recruitment process, and that they are either deliberately setting hard deadlines as part of the test to see how candidates react, or are happy to accept partially-done or low quality answers. Having seen the way these tests were handled by my own employers when I was a core part of the recruitment process, and as a candidate, I fully subscribe to a variant of Hanlon's razor here, where the intent is to give a fair test that can be achieved in a reasonable amount of time, but the end result does not work that way.
I think the following factors combine to make the actual task time larger than it should be:
Companies are often interested in making a task complex enough that it tests code structure and design issues.
After designing a moderately complex task, wishful thinking by staff involved in the rescruitment encourages them to make estimates that may seem do-able, so that candidates will apply, and the recruiters feel reasonable about themselves.
Familiarity with the problem description by the people designing the task can make technically competent staff give low esitimates.
Companies setting new interview tasks rarely sense-check any part of them by having existing staff not involved in the interview design perform them.
Best practice code writing, iterating on designs, documentation and unit tests are often not considered or only partially considered when estimating. This is a common problem with estimates on real-world tasks too.
Candidates, eager to impress, and not being observed carefully, will often underplay the extra time they put in to polish a task. They may well have an idea conceptually solved in the first hour or two, and then spend two to four times that polishing the end results, getting good code coverage etc.
Candidates that present great code with best practice and lots of polish are noticed when the code test is analysed in isolation, and more likely to be put forward with positive comments about the test solution.
If it is not checked automatically, then the time taken to complete the tasks is rarely checked, or followed up. Even when it was obvious that someone put far beyond normal effort into a task, or the information volunteered this was not raised or seen as a negative point against their recruitment. What was noted was the quality of the work.
When I have worked on recruitment tasks I have seen evidence of these issues. As a candidate I have experienced a wide range in how reasonable the real length of tasks and time estimates can be. Many companies do manage to set technical tests that are achievable in two hours, and many do not.
A reasonable compromise is to use an automated test which somehow times the candidate - emailed instructions with 3 hours to respond (triggered by candidate), or online resources like HackerRank can both work. Timeboxing the tests in this way may be unfair or awkward for other reasons (it sets up exam-like pressure for instance which is not realistic in a real job), but at least it limits the time investment expected from the candidate.
Whatever the reason, the test is set up by the employer, and as a candidate you are not usually in a position to change or challenge their process. Unfortunately, you are also undermined by other candidates competing for attention and willing to put extra effort in.
I would not advise you to comment or push back on any recruitment tasks, unless you are feeling confident that it will be well received (have you already spoken to the hiring manager, and did they suggest you could contact them about the task). In each case you have to make a judgement call on whether you want to perform the task, and how much effort you want to put in for the role. Treat the time estimate like you would if a colleague had done the estimates for some task that you go handed, and forgot about some details, so it could be quite a bit out unfortunately.
In the last year, in a similar situation to your question, I tried time-boxing myself to the suggested time (1 hour). I produced a script (in Ruby) that did everything that was asked for. In the same overall test I also produced code that demonstrated that I understood good use of class composition and unit tests - there was a separate more focused tech test as well as the more extended task. So I decided that it would be OK not to "polish" the tech task script, just demonstrate that I could analyse a problem and produce code to solve it. Result: I was rejected with a comment that my code was not well structured and that they were expecting unit tests. I believe that is due to one or more of the driving factors I listed above.
So my advice is: Decide whether you want to apply based on your assessment of the task length, and whether you want to give up a week of evenings or half your weekend just to apply. Then either apply with your best attempt at the task, or politely decline.