Admittedly it's not much of an opinion on Rust as a language but rather the size and performance of its compiler. And I can understand why Rust advocates would see it as a criticism of the language...because the language and the compiler are heavily intertwined. I can also see that there are extremely valid use cases for small and simple over big and complex, and in those use cases, Rust is absolutely a bad fit.
I do, however, think it is odd that OpenBSD would value compiler size over security, given the philosophical values of the OpenBSD project. I would expect that sort of opinion (and agree with it) in the NetBSD project, but I would think that OpenBSD would be willing to put up with big compiler binaries and slow compile times in exchange for even small improvements in memory safety. Strongly and statically typed languages in the ML tradition (like Rust, SML, OCaml, Haskell) all have big bloaty compilers, but that is for a specific reason: the type system that prevents you from compiling invalidly-typed programs is in essence a test suite. And for rust, a language with a type system that covers memory safety bugs, that test suite is massive.
OpenBSD is pretty famous for the comprehensiveness of its test suite, perhaps only superseded in depth by applications that lack its breadth (such as SQLite). I've never run the full OpenBSD test suite in a development cycle, but I've heard stories about running it that perhaps parallel the frustration newbies have with getting rust programs to compile.
What would an OpenBSD test suite look like if it could conclusively prove the absence of all memory safety bugs? Would Theo De Raadt be willing to put up with a test suite that ran for two hours longer and required more memory than could be allocated on i386 systems if it could do so? I think he would...because that is something in line with the OpenBSD philosophical values. So why is it that it needs to compile code so efficiently, if you're gonna turn around and run tests for 3 days to make sure nothing breaks?