Yes, I've been doing it since around 2003-2004. I've never been on any core team or council and tend to go off and come back, but usually stick to a project for a few years (except random drive-by PRs when I found a bug and feel able to solve it without weeks of research).
Why? First of all I like software with less bugs, so that's what I tend to do, all my greenfield development usually happens in my own toy projects. One of the reasons is that I don't have to think about long-term quality and getting it exactly right, like at $dayjob (mostly for architectural decisions, obviously I try to fix the bugs properly...).
A smaller part is also just giving back. I've profited immensely from open source stuff over the last 24ish years, including most of my income in the first years.
That said, I also take extensive breaks. If I don't feel like coding outside of work for a few months, I won't - that's also one of the reasons I am not interested in leading a bigger project, although just doing some releases or merges and bugfixes once in a while is perfectly fine.
I don't think anyone must feel pressured to contribute to the greater open source system, but I absolutely ask any 'bystanders' that they're not entitled to anything, including prompt replies or bugfixes - but if I see that a prolific open source contributor has a problem I might be expediting that issue. (Yes, I might be doing the meritocracy thing wrong :P)
Regarding "at the workplace" - sadly it diverges greatly from employer to employer. I had jobs where there was no question whether I get a day to investigate a bug and properly repro and report it upstream (or do a fix), and others where it was more like "no you can't do that" (and then sometimes I fixed it at night on my own time, but rarely) and many in between. But in my experience it's usually in the company's best interest if the developers understand the things they depend on and have familiarity with the code base, so upstreaming stuff should be a nobrainer... so it has mostly worked out for me.