Das Decorator-Muster bei der Konzeptionierung einer Software zu berücksichtigen, zahlt sich gleich aus mehreren Gründen aus. Allen voran steht das hohe Maß an Flexibilität, das mit einer solchen Decorator-Struktur einhergeht: Sowohl zur Kompilierungs- als auch zur Laufzeit lassen sich Klassen gänzlich ohne Vererbung um neues Verhalten erweitern. Zu unübersichtlichen Vererbungshierarchien kommt es bei diesem Programmieransatz folglich nicht, was nebenbei auch die Lesbarkeit des Programmcodes deutlich verbessert.
Dadurch, dass die Funktionalität auf mehrere Decorator-Klassen aufgeteilt wird, lässt sich außerdem die Performance der Software steigern. So kann man gezielt jene Funktionen aufrufen und initiieren, die man gerade benötigt. Bei einer komplexen Basisklasse, die alle Funktionen permanent bereitstellt, hat man diese ressourcenoptimierte Möglichkeit nicht.
Die Entwicklung nach dem Decorator Pattern bringt jedoch nicht nur Vorteile mit sich: Mit der Einführung des Musters steigt automatisch auch die Komplexität der Software. Insbesondere die Decorator-Schnittstelle ist in der Regel sehr wortreich sowie mit vielen neuen Begrifflichkeiten verknüpft und damit alles andere als einsteigerfreundlich. Ein weiterer Nachteil besteht in der hohen Anzahl an Decorator-Objekten, für die eine eigene Systematisierung zu empfehlen ist, um nicht mit ähnlichen Übersichtsproblemen wie bei der Arbeit mit Subklassen konfrontiert zu werden. Die oft sehr langen Aufrufketten der dekorierten Objekte (also der erweiterten Software-Komponenten) erschweren zudem das Auffinden von Fehlern und damit den Debugging-Prozess im Allgemeinen.