If they really didn't provide you any more information than what you mentioned in the post and comments and you won't even be permitted access to maintain the server, I wouldn't complicate too much. Even if you could do more, you'd be guessing, and probably make life harder for the researchers who might not have the expertise having to actually maintain something too complex.
Do the bare minimum to make it functional and overall secure, make sure the operating system works, get SSH access configured for as few people as you can get away with, and make sure updates are installed automatically. They should be responsible for everything else and you should make that clear to them (backups, software, etc)
Provide notes on what you did to the future owners of the server and maintenance instructions as well.
If you are part of an IT team in the university, and if you have some leverage on it, make sure you have the authority to handle things on an emergency (like having the right to pull the plug if the server becomes rogue or misbehaves somehow). Also look to see if you can push them to a more standardized alternative, if your IT team provides standard services look to see if their use case can be fulfilled somehow by them, even partially. I know a lot of universities provide code forges and job submission clusters students and teachers can use, maybe their use case fits these.
Language isn't everything. While Rust provides some features and safety that C doesn't while being roughly equivalent in performance, the algorithms that developers choose will dominate the performance impact on the program.
GNU core utils has decades of accumulated knowledge and optimisation that results in the speed it has. The Rust core utils should in theory be able to achieve equivalent performance, but differences in the implementation choices between one and another, or even something as simple as the developers not having prioritised speed yet and still focusing on correctness could explain the differences that are being reported.