> that

should be

> than

in your comment.

Aside that, I did not make any arguments either way regarding your question. But, I am not sure that your question makes sense in this context, for the developers that are available to a given project are generally part of the considerations for that project. For instance, if a company has a number of existing employees and are not in a position to attract new ones, the existing employees absolutely have to be considered, even ignoring any negotiation kind of stuff. Conversely, if a company has no current employees (like a newly minted startup) or is in a great position to attract lots of new employees, then the company at least has the option of selecting new employees to fit the rest of their goals and constraints. Though even in the latter case, considering existing employees can often make a lot of sense or be necessary.

For Canonical as well as the Linux kernel, I think I have heard arguments about attracting new developers by switching to Rust, and there has on the other hand been concerns regarding existing developers, not all of whom might be interested or experienced in Rust, some existing developers have complained in public. But there is a lot of know-how, expertise and domain knowledge independent of the language in both the Linux kernel and the software that Canonical handles or uses, and that knowledge and expertise are not necessarily easy to acquire quickly. And then there are all the borrow checker problems and other kinds of problems with Rust, making Rust, even for greenfield projects, less attractive. Rust does have nice pattern matching, though.

I believe that one should optimize for the needs of the business that uses the project/software. SaaS, Open Source and internally used proprietary software have different optimization parameters.