As you pointed out, I don't see any advantage to a DistanceFrom "operator" over creating it as a UDF.

The advantage for the UDT is that it is a CLR, which means it's accessible in the middle tier.  You don't have to connect to the SQL Server to get access to the business rules tied into the UDT.  This is right up the alley of the DBA who believes that business rules should never be written in stored procedures.  This is extremely threatening to the DBA who believes that business rules should never be written anywhere else.  This might be a bridge solution where the developer can design what he/she wants stored and the DBA can keep the schema away from the ignorant developer while still being able to see what is being stored on "his" DB.

Never underestimate the capacity for idiotic behavior in any human.  I've been on the programmer side, where I know what data I want stored, but have to pass the request on to a DBA who can't do what I want done unless I correct his "solution" 15 times.  I've been on the DBA side where I've seen the devastation a programmer can do to a DB because they don't understand what they are doing and are allowed to modify the schema.

I can see it now, the DBA doesn't allow direct access to the table and will only allow the developer to send/receive the properties of the UDT in sprocs.  And of course the DBA screws up what properties are allowed in the UDT.