From the documentation:
Additional hostkeys are only accepted if the key used to authenticate the host was already trusted or explicitly accepted by
the user.
This means it will not accept arbitrary host keys from anybody but only accept these keys from an already trusted host. The idea behind this option is also clearly explained:
... learning alternate hostkeys ... graceful key rotation by allowing a server to send replacement public keys before old ones are removed.
Since the option does not introduce any security problems it is also enabled by default:
UpdateHostKeys is enabled by default if the user has not overridden the default UserKnownHostsFile setting, otherwise UpdateHostKeys will be set to ask.
The reason that it is not enabled when the user defines its own UserKnownHostsFile is probably because in this case it can be assumed that the known hosts are managed not only by ssh itself and that ssh will not infer with this external management by default.
The also means that UpdateHostKeys no will not by itself introduce new security problems. It might make the time harder for the user though in that it will fail to connect to systems when they've rotated their host keys. Instead the user then needs to manually accepted the new host key, and this might lead to a security problem if the user blindly trusts the presented host key instead of properly verifying it. Thus UpdateHostKeys yes can actually improve security by automatically updating a trust relationship instead of asking the user to manually (and maybe wrongly) doing this.
I don't understand though how UpdateHostKeys no fixes a specific problem - and unfortunately you only show the proposed solution and not the problem it was claimed to solve.
