Here is the answer; When you wish to provide a library that you intend for use in diverse applications[1] -- and OpenSSL is a excellent example of exactly this case -- you cannot choose a language with a complex runtime. Go has a complex runtime. There is no getting around this; any non-trivial software implemented in Go will require a number of runtime facilities and accommodating that becomes a burden for the library user.
Rust has about the same runtime burden as C/C++. It links the same way as C/C++ and imposes the minimum possible burden on the library user.
[1] diverse as in essentially all platforms, from microcontrollers to high performance systems at scale, over decades of evolution.
Languages with non-trivial runtimes like Go or Haskell just don't support that same model. You would want to convert your libraries in a certain order so there is one continuous C vs non-C boundary.
They have more information on their website about how to give them money than they do about who they actually are. This makes it easier to route cash to rewrite-it-in-Rust efforts without having to defend these decisions.