Sehe ich auch so. Eine strikte und klare Trennung macht oft sehr viel Sinn, ist aber manchmal auch unnötig.
Z.B. würde man die Panel.Font-Eigenschaften nicht direkt im Panel veröffentlichen. Wozu auch? Man kann zwar argumentieren, dass das logischer wäre, aber es wäre ein Aufwand, der letzlich keinen wirklichen Nutzen bringt.
Außerdem müsste man dann konsequenter Weise auch die Canvas-Propertys usw. direkt im Panel veröffentlichen. Das macht nicht wirklich Sinn.
Man muss sich also in jedem Anwendungsfall für die beste Verfahrensweise entscheiden. Dass man dabei die Grundlagenb (LoD usw.) berücksichtigt, ist natürlich sinnvoll.
Im Beispiel dest Kaftstoffs würde ich in der Realität im Handbuch des Fahrzeugs nachsehen, was ich tanken muss oder andere fragen oder in einer Tabelle nachlesen. Das lässt sich in der Software so nicht sinnvoll nachbilden. Jedenfalls nicht, um lediglich die Tankstofffrage zu klären.
Also entgegen der Realität ist es in dem Fall am einfachsten, den Motor zu fragen, was er denn tanken will. Wie man das im Detail realisiert (ob man direkt Auto.Motor.Kraftstoff anspricht oder die Abfrage in einer Funktion Auto.GetKraftstoff kapselt) und ob man dabei mit Objekten oder Interfaces arbeitet, ist dabei m.E. nebensächlich.
Insofern ist das ein anderes Thema, das zwar durchaus wichtig ist, aber nicht in aller Konsequenz durchgedrückt werden sollte.
Für mich ist die Frage interessanter, wie die Objekte (deren Schnittstellen weiter verwendet werden) ertzeugt und verwaltet werden.
Wer ist Owner der Objekte? Gibt es Verschachtelungen? Wer kümmert sich um die Lebensdauer der Objekte?
Im Moment schlage ich mich mit eingen Seiteneffekten herum, die sich gelegentlich bei meinen Objekt-Verwaltungen und den komplexen Beziehungen ergeben. Dabei verspreche ich mir Verbesserungen bei der künftigen Verwendung von Schnittstellen und einer zentralen Objekterzeugung.
Im Moment muss ich aber erst nochmal die Kühe einfangen. 
Wenn man auf die Owner-Verkettung verzichtet, muss man die Beziehungen der Objekte natürlich anders abbilden. Aktuell kann ich für tausend Objekte einfach das OwnerTournament interativ ermitteln.
Ohne diese verschachtelung müsste ich für die tausend Objekte eine neue Eigenschaft einführen, die auf das Tournament-Objekt verweist. Führe ich das als Pointer aus, mag das noch gehen. Speichere ich aber die (ggf. lange) Id, geht das auf den Speicherverbrauch.
Das sind die "Probleme", die mir aktuell noch Kopfzerbrechen bereiten...