I am not sure what to do about the burnout problem. The way he described it is very on point though. Since everyone working on the project is overloaded there is a great feeling of things only get done if you do them.
Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating.
Pacing and self-regulation. It’s a marathon not a sprint. Set an hours-per-week budget. Beyond that things just don’t get done. That’s okay.
If the community needs faster pace, they can consider supplying hours or dollars to fund more developers to work full-time.
Also, and this can be the hard part, is sometimes you have to have someone who (even politely!) can be a bit of a dick when necessary. People scan be quite entitled and want to boss everyone around and tell them the project is run wrong - if you don’t actively run at least some of them off the devs will curl up and disappear.
Also having a defined procedure for “hiatus” helps quite a bit - make it easy for a dev to say “I’m off” and it can be indeterminate - this allows them to easily come back later. Encourage devs to use it liberally.