Suppose that on June 1, 2020 there was a data breach that leaked the private key for yourbank.example.com's certificate, and on June 2, 2020, the certificate authority that issued your bank's certificate included a revocation for that certificate. Anyone who requests and receives the current status of that certificate between June 2, 2020 and the time the certificate would have expired would receive a notification that the old certificate was no longer valid.
If, however, the computer's clock were set to August 1, 2019, an attacker who knew this, and who had control over the computer's Internet connection could direct connection attempts to a variety of phony servers, including one which would claim that the date was August 1, 2019, and one which would claim that the yourbank.example.com's certificate had not been revoked (as of August 1, 2019, it would not have been). While attackers' ability to exploit this might be limited for computer-clock values that are in the recent past, the further off the clock is allowed to be, the greater the possibilities for mischief.
Such issues create something of a catch-22 for systems that will only be connected to the Internet very rarely (e.g. once every few years), and may not know the date when they do connect. Without a means of knowing whether a time server's certificate is still valid, one would have no way of knowing whether the reported time from what seems to be a time server might be maliciously manipulated. Requiring that users set the time and date may be crude, but if the user is paying attention, it should protect against that sort of manipulation.