Comprendre que Moodle.org a cessé depuis les versions 3 de fournir un ensemble de variantes de thèmes en standard, car ils se sont rendus compte que :
- les demandes étaient considérablement divergentes entre les différents exploitants
- que le theme est un endroit systématique d'une très grande customisation
- que de nombreux développeurs se sont attaqués à fournir des thèmes très divers et souvent très "développés", secteur très prolifique dans l'ensemble de l'open-source, vu l'importance (surévaluée ?) croissante du look sur le fond (je parle pas de la modification ergonomique ici) et le rayonnement communautaire d'un tel développement (par rapport à des propositions plus "enterrées").
Moodle.org a donc préféré offrir une API puissante des thèmes facilitant et favorisant les surcharges et la création d'une surcouche, plutôt qu'avoir à se taper la vérification et la maintenance des dizaines de fonctionnalités ajoutées par les développeurs de theme.
Avec les themes standard, vous avez donc l'essentiel (le minimum vital), que Moodle.org essaie au fur et à mesure rendre le plus "clean" (d'où le nom du theme) possible. Mais sans fonctionnalités ajoutées ni fioritures graphiques.
Les themes standard acceptent maintenant une réingénirie en scss (variantes) mais elle est "technicienne" et demande des compétences en "coding" de style et en Javascript.
Les thèmes non standard vous apportent ces surcouches déjà programmées et à nouveau paramétrables par un administrateur (au prix d'une certaine complexité de paramétrage). Ce sont deux approches diamétralement opposées. Les intégrateurs et Moodle Partners préféreront la première, car elle protège leur compétence et savoir faire. Les exploitants apprécient plutot la deuxième, car la dépendance au prestataire est moindre.