You just don't get it. You're assuming that a function is perfect, that its code is provably correct. Well, we were originally talking about integrating new, not-broken, correct code into a code body which is incorrect, so that assumption is immediately useless here. Further, if your code is correct and perfect, why would you come back to modify it?
We're coming in to clean up bugs. Now we're taking code and integrating it from one changing code base into another changing code base. The new code may work properly, while the old has corner cases that break synergistically: some body of code may work properly only in the presence of a defect in some other body of code. Microsoft Windows' source code was published a decade or so ago, and it was rife with this--hacks on top of hacks.
Do you honestly think that this can be done by just "checking the function for correctness"? You've integrated some correct code from another codebase which now makes this part of your code correct. Unfortunately some other part of your code now fails and, in the most extreme cases, we've created a new exploitable condition!
So now you have to go back and assess impact. By changing this function, you change a lot of other code. That code has the same logic, but different data coming to it--it's the same cog shoved into a different machine. You can do analysis to see if your new function does anything different than the old function, if the conditions its output precipitates on can now produce different output. If you can't prove that it doesn't produce different output in some situations, then you must now assume that your program changes may have wide impact. This includes if your output may be between 1 and 255, and it is, but it may return 47 instead of 42.
You can reduce the probabilities, but you cannot eliminate the risk. OpenSSL merging LibreSSL code without doing impact analysis and making sure the new code doesn't open new vulnerabilities will incur risk. Hell, LibreSSL will face the risk of creating new vulnerabilities as it goes, so you may eliminate 100 problems and cause 1 and that's okay because you are 99 problems better. The risk OpenSSL faces is greater, because they may import defective code from LibreSSL, or they may import code that works but which is no longer broken in such a way as required by other (still broken) code present in OpenSSL but no longer in LibreSSL.