Which is a great point - how are we actually mentoring the junior engineers so that they can take over some day?
More that it's pointless to contrinute to an open source project if you're not interested in improving the software the project is building for a reason that matters to you. That's true regardless if you know what you're doing or not.
So if your objective is just to "get a PR merged" that's not really helpful. Rather it should be to "fix this bug" or "add this feature" because those things somehow matter to you.
The "you" can also mean your employer. So if you use some software as part of your job and it's got a bug or is missing a feature that matters enough to you then fixiing it and contributing it back is a perfectly valid and great way of funding open source. It's also not normally philantropic, because when you make the effort of getting your changes merged upstream it also reduces your own long term maintenance burden of having a private fork.
I'm not talking about open sourcing something your company has made from scratch and is their core product but just contributing (usually small) imporovements made to some open source used so the "giving away IP argument doesn't really hold water".
In my experience that's an easy sell to the company on purely practical / selfish terms ("we can keep it in house and have to spend time reapplying our changes to each new upstream version that comes out or we can submit it upstream and have easier updates in the future").
Look at all the companies contributing to the Linux kernel in each release, most of them do it for precisiely this reason.