There is always a simple answer to such question, and it's usually about some inconvenience the service provider decided to set-up for the user. In this particular case I think the answer is obvious: email provider usually have a session which never really ends, and just sits there logged in unless the browser cache is wiped.
Make your service auth token to live for the same time as Gmail's, and as an alternative give users an ability to just login with OTP every time, but stop these unholy 12 hrs time-to-live auth token practices - your users will never log-in via password restore again.
The real reason may be that the websites in question simply do not work.
I have had troubles with Epic and Spotify accounts in the past. I make an account, I use it for a week, after a week session expires - Spotify kicks me out of my account. I try to log in, it says my password is incorrect. This is impossible, because my password is saved in my password manager. So I have no choice but to reset through email. First several times I receive the email, reset the password, the pattern repeats, after 3 or 4 repeats I don't even receive the email anymore, so I am forced to make a new account.
Currently I am logged into Spotify through my Google account, where I have zero issues so far. But if I use plain email, their auth system simply does not work.
I think this is closer to hinting at the truth. GMail and Cloudflare (and many other "high security orgs) have very long auth sessions. Why? Because the chance of somebody getting onto the PC of someone who uses these systems and hasn't logged out is actually really low. Most hacks are remote and based on weak passwords.
Unfortunately, we lack the consistent language to measure risk and decide "do I really need 2FA on this site?" "Is 30 minutes a reasonable session time?". I think as long as someone has an up-to-date virus checker, most would rather stay logged in to stuff. Anyone ever been asked to delete all cookies to fix a problem on a site? My answer is always to "go fish".
I remember somebody saying before, "it's your account, if you want to stay logged in and risk a hack, it's your risk not the company running the service". I believe that more and more. If your laptop is logged in and someone deletes all your EC2 instances, that's on you, not AWS for not logging you out sooner. They could but why should they? Piss off 1M users to try and protect 1 person who is too careless?
I also hate password expiration rules. A true manager's "bright idea" which is horrible for security. Once I was registered on a service which required a password change every month, so every single month I had to change a letter or number in my password, because they also stored all my previous passwords and did not let me just swap 2 passwords around, forcing me to create a "new" one every time. BTW my password is 24 characters of solid gibberrish which I can only remember by chanting a long mnemotechnique in my head, obviously never leaking anywhere and unpickable. So changing it is not easy. At some point I was so mad when I could not change a password in a way it did not repeat any of my previous modifications and still remembered easily, so i just put qwerty123 in, needing to log-in into service desperately. It was bruteforced days after.
There is always a simple answer to such question, and it's usually about some inconvenience the service provider decided to set-up for the user. In this particular case I think the answer is obvious: email provider usually have a session which never really ends, and just sits there logged in unless the browser cache is wiped.
Make your service auth token to live for the same time as Gmail's, and as an alternative give users an ability to just login with OTP every time, but stop these unholy 12 hrs time-to-live auth token practices - your users will never log-in via password restore again.