People tend to contribute to the projects they already have the skills for.

People also tend to pick up new skills when they have a driving incentive to do so, like supporting a project they have a vested interest in seeing improved.

You need to learn the language's structures

Most of the bread and butter ones have analogues in other languages you should readily understand. More language-unique structures are rare; the more niche they are, the lower the odds your ability to contribute in a meaningful way hinges on your understanding of them.

you need to learn how the compiler works

You really don't, though? Modern compilers, particularly the Rust compiler, are designed to abstract away as much of the details of compilation as possible. If the project really does need to tickle the compiler a certain way to get it to build, it will almost certainly have a buildscript and/or a readme.

you need to learn the libraries that the FOSS project is using

This is true regardless of the language in use. I'm not sure why you brought it up.

you need to learn the security pitfalls for the language

I would imagine most of these language-specific security footguns are either A) so specific that you will never hit the conditions where they apply, B) are so blazingly obvious that code review will illuminate what you did wrong and you can learn how to fix it, or C) so obscure that even the project owner doesn't understand them, so you'd be at minimum matching the rest of the codebase quality.

Mind, I am not insinuating that one can simply bang out a whole new submodule of a project in an unfamiliar language with minimal learning time. Large contributions to large projects can be hard to make even when you're a veteran of the language in use, as the complexity of the project in and of itself can be its own massive barrier. But not every contribution needs to be big. And for most contributions, I don't believe the language is the most significant barrier to entry. It's a barrier, sure. But not the biggest one.

I'd wager it's not having a significant impact on the volume of contributions to Lemmy in particular.

I'm not sure that it's a complaint from them, so much as an explanation. It's important to realize that developers are human beings with human needs, wants, and feelings. The popularity of Lemmy is not their "fault" and the language choice is rather fundamental to the project itself. Would it be nice if some features were taken up more quickly or implemented in other ways? Yes. But others needs, wants, and feelings are not more important than those of the devs. They need to eat, sleep, provide shelter for themselves, and, importantly, do things that are not coding (for physical, social, and mental health).

The number of people who understand Rust, can code in it, know of Lemmy and want to contribute is very few. There would be More developers contributing to Lemmy if it weren't written in Rust.

And there would be more developers if more people wanted to learn Rust. The low number is just a fact to accept. If one can't accept it, there are plenty of other platforms.

Would you be criticizing them equally if, instead of Rust, they created the project using FORTRAN and made a point of mentioning explicitly that using FORTRAN was the main intent? It's just a weird criticism to me - Lemmy is fundamentally a project started so that the devs could work with Rust. You are criticizing them for their project not fundamentally being a different project. Maybe another comparison would be criticizing specialty water-based paint manufacturing for using a water rather than a VOC-solvent for water-based paint - they're not trying to make other types so, the criticism doesn't make logical sense.