Using a similar approach in my own Laravel-based CMS that I've already battle-tested in production, including the relatively high-traffic client projects with 3-5 mln visits a day, I could not agree more, it's a completely viable approach.

In my system, I use enums as sort of a high-level map/factory/strategy that pulls up logic depending on the requested content block type. That logic is encapsulated in separate classes that I call blueprints. A single content block type has only one blueprint. The blueprint describes validation rules and form fields for the content block and its methods, satisfying a couple segregated interfaces.

In theory, it's an awful god class. In practice, I have a well-tested, deeply automated and extensible system that allows me to simply add another class that implements the required interface(s) in order to extend my system to work with another custom content block, and simply register it in the single ContentBlockType enum's mapping.

That's it. I can use a single FormRequest class that defers validation rules to a Blueprint through that enum, based on the content block's type. The blueprints for different blocks have a consistent, high-level behavior definition, and their methods don't actually perform changes, deferring instead to a layer of services — either project-wide, or specific — which also have their boundaries defined with interfaces.

The code is extensible and highly readable, testable, leverages DTOs for type safety, and doesn't require a sophisticated IDE. The purists would burn me alive for this, but that's on them. I have proof that my system works, it makes my clients happy, it brings the flexibility of a headless CMS to a monolith, and it makes extensions a breeze for everybody, while the god of god classes seems to be very pleased and kind.

Programming is about solving a problem. Just keep things reasonable, define boundaries, and stay consistent overall. Then solve the problem in the most efficient way. That's really it.

The Intermediate Developer Trap