Eine Klasse soll ja nach den OOP-Regeln so abstrakt geschrieben sein, dass man sie oft wiederverwenden kann.
Wenn ich nun aber in eine Superklasse zum Beispiel für eine PictureBox nur ein paar wenige Methoden schreibe, die ich auch wirklich brauche, ist die Wiederverwendbarkeit in anderen Projekten ja eher gering - natürlich könnte man entgegnen, dass ich einfach eine Unterklasse ableiten und Methoden hinzufügen könnte.

Aber wenn ich dies tue, müssten ja die signifikanten Methoden, die ich dazu noch einmal benutzen möchte und vor allem die Instanzvariablen - bei der PictureBox mit Sicherheit das Bild - ja alle protected anstatt private sein.

Heißt das nun, dass ich von Grund auf alle Instanzvariablen und Methoden protected machen sollte, weil es sein könnte, dass wenn ich die Klasse weitergebe oder selber wiederverwende, Erweiterungen davon schreibe?

Wenn du diese Anforderung so eng formulierst, ja! Wobei ich die Einschränkung machen würde, nicht wahllos alle Methoden und schon gar nicht Variablen protected zu machen. Überleg dir, welche Methoden im Kern zu der Klasse gehören und diese würde ich dann protected oder auch public deklarieren. Klasseninterne Hilfsmethoden sollten private sein. Je nach Fall kann auch der Einsatz von Gettern (z.B. für das Bild) sinnvoll sein.

Auch wenn es mir bei deinem Beispiel einer PictureBox (ohne genaueres über deren Funktion zu wissen) ein wenig überdimensioniert zu sein scheint - wenn du so hohen Wert auf Wiederverwendbarkeit legst, definier dir Interfaces und zieh deine Logik in eigene Klassen, die diese Interfaces nutzen (als Parameter oder selber implementieren).
Dadurch hast du ein modulareres Design, was aber natürlich von den Interfaces abhängig ist, die du in zukünftigem Code eventuell nicht willst.

Meiner Meinung nach gehört es sich nicht Attribute einer Klasse als protected zu markieren - gerade, um diese wiederverwenden zu können! Denn dann habe ich keine Möglichkeit mehr den Typ oder andere 'Seiteneffekte' dieses Attributes an einer Stelle (OO-lässt grüßen!) zu kontrollieren (ändern oder Aktionen ausführen). Viel besser ist es IMHO entsprechende accessor-Methoden zu schreiben, um die Attribute zu manipulieren / zu lesen. Das ändert sich genau dann (schlagartig), wenn das Attribut als final deklariert ist - es sich also um eine Konstante handelt. Dann darf diese auch gerne sogar public sein. Aber auch hier gilt immer das Hirn eingeschaltet lassen und sich fragen, ob diese Konstante überhaupt sinnvoll von Außen (und welchem 'Außen'?) verwendet werden kann. Wenn es im aktuellen Projekt keine Notwendigkeit gibt das Attribut/die Konstante zu veröffentlichen, sollte sie auch weiterhin private sein. erst wenn man feststellt, dass der Wert woanders auch wirklich benötigt wird, sollte über eine Ausweitung der Sichtbarkeit nachgedacht werden. Durch dieses Vorgehen können Klassen bei bedarf einfacher refactort werden. Ein Codeschnipsel ist einfacher um zu biegen, je lokaler die Auswirkungen auf die Änderungen sind - und das kann über die Sichtbarkeit gesteuert werden.
Meine Erfahrungen (> 10Jahre SW Entwicklung) lohnt der Aufwand immer ein Attribut mit accessoren zu bedienen und auch die Sichtbarkeit der Fragmente entsprechend einzuschränken.
Ich will hier keine Flamewar starten, aber für mich sind Attribute mit anderen als private Sichtbarkeiten schlechter Stil!