Salut,
D'une manière générale, on peut relever pas mal d'avantages :
- Ça permet de se forcer à organiser son code selon des standards généralement bien fondés (ou, au moins, bien appréciés par les collègues qui reprendront ton taff)
- Ça fournit une base de "boilerplate" assez conséquente en général, c'est-à-dire des morceaux de code ultra fréquents déjà intégrés dans le framework, histoire de pas avoir à se retaper 40k fois dans sa carrière un même module banal. En plus, ces boilerplates sont par principe particulièrement éprouvés (et surveillés par la communauté),ce qui limite les risques d'erreurs (notamment sur les modules sensibles) et peut améliorer la qualité.
- Dans le même état d'esprit, un framework étant souvent accompagné d'une communauté, ça permet d'avoir une base de développement solide, testée concrètement et théoriquement avec moins de bugs.
- C'est aussi une plateforme d'extensions : dans le cas de Ruby on Rails, on a un nombre hallucinant de gems (plugins, en gros) qui s'installent en un instant, et dont l'utilisation est grandement simplifiée par la présence du 'noyau' commun Rails.
- C'est tout un écosystème qui s'intègre généralement parfaitement aux autres outils et pratiques du langage : débugging, tests, migrations, ...
Bref, y'aurait encore plein d'autres avantages. L'intérêt c'est vraiment d'avoir un développement accéléré (et un temps 'optimisé', pas passé à répéter 36 fois les mêmes choses), une structure de code et l'appui d'une communauté, de telle sorte qu'aujourd'hui toutes les grosses boîtes tournent sur un framework.
Après, t'es pas obligé d'utiliser les frameworks standards de ton langage (de nombreux développeurs ne le font pas, d'ailleurs) : tu peux tout à fait créer ton propre (mini)framework. S'il est bien fait il devrait regrouper tous les avantages précédents (sauf peut-être la communauté) et d'autres plus adaptés au développeur/l'entreprise. Utiliser un framework, avant d'être un outil concret, c'est aussi un 'principe' d'optimisation de son temps de développement.
