No, Bitcoin does not have the same problem.
An extremely large number of cryptocurrencies are essentially completely centralized and only pretending to be decentralized as a regulation dodge. Centeralized systems can be extremely secure-- until the central parties decide to screw you over.
Bitcoin does have a thing called "checkpoint" but it is essentially completely unrelated to the centralized consensus mechanisms (usually a broadcast message signed by developers that force all nodes to switch to a chain with blocks that they've signed) added to many other altcoins which have used the same name for deceptive reasons to disguise their centralized control.
In Bitcoin there is a problem that the minimum POW difficulty was set based on 2009 CPU speeds just hundreds of thousands of hashes per-second, so at minimum difficulty a block requires 2^32 hashes to create. A single modern asic miner can perform 68 trillion hashes per second using a couple kilowatts. So, one of these devices could generate about 16k blocks per second at minimum difficulty.
This creates an issue where an attacker could fork the chain early on and create an incredible number of blocks at the minimum difficulty and feed them to your node. Your node wouldn't be sure if this chain of minimum difficulty blocks might not eventually add up to more work than whatever is your current chain, so it stores them. Eventually, this would exhaust your memory and disk and crash your node.
Currently, this attack is blocked by checkpoints that cause your node to ignore forks created from the chain back before the difficulty reached ~2^32 back in 2014 (so 2^64 work required to create a block). That's all checkpoints do.
There are alternative proposals to eliminate this problem which people are working on from time to time... and which have included adding consensus rules to increase the minimum difficulty (except for the earliest blocks), or making it possible to efficiently produce a compact proof of the total work behind a particular best block. But changes to consensus rules are fairly slow and hard to accomplish, so for the moment the adhoc fix protect nodes from an otherwise completely practical attack. Once one of these other fixes is implemented the 'checkpoints' would go away completely.
And never did they operate like 'checkpoints' in most other cryptocurrencies.
> client ever reasonably revert to a chain back in time 1 day without human intervention
Refusal to reorg at threshold X (for whatever X you choose) only creates vulnerabilities it doesn't resolve them:
Consider, if an attacker can't create enough blocks to produce a reorg X back from the tip then a refusal to reorg would simply be pointless (because the expected attack couldn't happen), so implicitly you're assuming the attacker can do that. If he can, then he can also create a fork right at X-1 and simultaneously announce it to whatever subset of the network he likes, carving the network into an arbitrarily shaped partition. If both sides have hashpower, both will continue on past block X-1 to X and and beyond on their own (and he can even contribute). They'll never heal on their own, the network becomes fragmented and exploitable in realtime. So the style of attack changes a bit but the ability of a supermajority hashpower attacker to reorg/disrupt the chain isn't materially reduced.
Worse, the refusal to reorg creates a whole new problem that didn't exist before: If a node was offline (say for days, months, years, or just coming online for the first time) then an attacker which didn't have anywhere near enough hashpower to successfully reorg near the tip could still (perhaps slowly over months) produce a X-long fork off an _earlier_ position in the chain and then aggressively feed it to nodes which are coming back online and redirect them into an attacker controlled bizarro-world which they won't recover from (without a user somehow discovering that they're on the 'wrong' chain and doing some unspecified action to fix them). This class of attack can be made more potent by DOS attacking a target's running node, forcing them to bring up new or backup nodes. This and similar attacks are an entire class of attacks created outright by a refusal to reorg.
Essentially the only case where a refusal to reorg is unambiguously safe is when you assume attackers lack the hashpower to cause the reorg in the first place. In which case... why bother?
As an aside, I think repeating an insult likening Bitcoin users to feminine hygiene products is extremely unprofessional and inappropriate for hacker news.