Wieder was dazugelernt:

Man kann, wie in C#, einem Getter oder Setter eine andere Sichtbarkeit geben, als die der eigentlichen Property.

Ich kann mich an keine Situation erinnern, bei der für mich ein Protected Setter für eine (z.B. Public) Property am meisten Sinn gemacht hätte.
Meine Gedanken dazu hier vollständig zu erklären würde ewig dauern, dasshalb kurz: Protected Sub SetFoo(NewValue As Bar)

In ein eigenes Topic ausgelagert. ~nikeee

Ok, ein ganz vereinfachtes Beispiel:
Jeder Punkt ist teil eines Raumes. Es kann keinen Punkt ohne einen Raum geben.
Warum auch immer der Punkt jetzt einen Raum benötigt. Es passiert in der Praxis öfter, dass Objekte gültige Verweise auf andere Objekte benötigen, damit sie korrekt funktionieren können.
Die X- und Y-Eigenschaften des Punktes zu ändern sollte jedem logisch erscheinen. Der Punkt befindet sich dann halt einfach an einer anderen Stelle. Das ist ja der Sinn von Eigenschaften.
Aber der Owner-Property einen öffentlichen Setter zu geben kann problematisch werden, denn das ist keine Eigenschaft wie X und Y, die man einfach so ändern wollen würde. Deshalb würde ich die ReadOnly machen und nur über den Konstruktor setzbar machen.
Sollte man es jetzt aber trotzdem mal wirklich benötigen, zuerst ein Point-Objekt ohne Owner zu erstellen und den Owner später zu setzen, würde ich eine separate Methode à la SetOwner verwenden und diese entsprechend dokumentieren, weil man sonst das Gefühl bekommt, dass man die Owner-Property nach belieben verändern kann.

Wie von nikeee13 angedeutet kann es durchaus gute Gründe haben, eine separate Methode zu verwenden.

Es geht nicht nur darum, dass Point.Owner = Nothing oder Point.Owner = EinAndererRaum ungültig wäre, sondern es geht darum, dass man das im Normalfall gar nicht erst probieren sollte. Und der Property einen Setter zu geben verleitet eben ganz stark dazu.