When you look at ScalarUDFImpl::equals, there is nothing wrong with it.
Problems happen when you do not look at it:

case a)

• add a normal struct implementing a function, i.e. implement ScalarUDFImpl trait
• add tests, perhaps with slt
• ... some time later ...
• make the function parameterized (add new field, like "time zone", "default value" or similar)
• add tests, perhaps with slt

case b)

• in the same LogicalPlan put two functions implemented by two different structs, for example regex_replace(string, string, string) with different regex engines

In both cases everything works great in tests, yet the real queries may fail, because the default implementation of ScalarUDFImpl::equals silently incorrect.
In case (a) it was because of evolution of the code.
In case (b) it was merely because two different functions can have same name & signature.

Expected

Default implementation of a public trait method should be less easy to get wrong.