Saying Scrum can't work because of those arguments is like saying that Scrum can't work in a company, because they are currently using waterfall. While Scrum and waterfall don't play well with each other (or rather contradict each other) it does not mean that you cannot establish Scrum there, if everyone goes along. Likewise I would not state that Scrum can't work in an open source project per se, but it comes with its own straits.
People tend not to work on Open Source projects full time
While this is true, Scrum embraces this kind of uncertainties, too. Given we have a very short cycle of one week, everyone that wants to contribute will have to commit for at least that one week and plan how much time they will be able to spend on the project. Based on how much time every contributor can afford, it's possible to plan the stories to work on. Anyway, doing Scrum won't be really possible, if the contributors tend to stay away from the mandatory meetings.
Of course this is not restricted to weekly sprint cycles.
While some projects have a group of core contributors many pull requests are ad-hoc with people submitting pull requests which most likely won't contribute to any agreed sprint goal
Open source does not necessarily mean that everyone can contribute like they want to. There are open source projects with very strict rules on how to contribute (Linux for example). People planning to contribute to the project will be required to attend the sprint planning, etc. You can make this a requirement to contribute to the project. Of course people disliking this may create a fork and work on this how they like, but this will be another project, then.
Communities are often run via messaging systems, blogs, and forums rather than formal meetings like plannings sessions, retrospectives, and sprint reviews
You can have the formal meetings via telephone- or rather videoconferences. While this does not make Scrum easier, it's well possible. Just because it is not done in the projects it does not mean that it can't be done.
The direction of projects is often more of a democracy (or whoever contributes the most) rather than being focused by a Product Owner
Yes, you will have to have someone who acts as a product owner. Again, the usual practice does not keep you from doing it differently. Furthermore, there are examples of single persons driving a project an steering it in one direction (again, think Linux).
Long story short, while you are probably correct that it's anything but the rule, I don't think it is impossible. If you have a competent owner chosing and prioritizing the user stories and contributors that are willing to contribute that way, nothing will keep you from doing Scrum.
Anyway - as was pointed out by the commentors - it's quite likely to be a mess and probably not a good idea. Just to mention some points why it might fail:
- It'll be hard to get a hard core of contributors - without it, Scrum won't play its strengths
- Without a very stable team you could roll a dice to estimate story points - it might work equally well
- with the Scrum overhead it will be even harder to recruit enough contributors
- Commitment levels will most likely not be high enough
(Side note: A Kanban-like approach might work better if you'd like to give some structure to your OSS project. It does not depend on roles, the buy-in is way lower and it's much more time-flexible, but still gives you a good overview of the WiP.)