The first CQ5 version I worked with was CQ 5.2.0 in late 2009; and since then a lot changed. I could list a lot of technical changes and details, but that’s not the most interesting part. I want to propose this hypothesis as the most important change:
CQ5 was a framework which you had to customize to get value out of it. Starting with AEM 6.x more and more out-of-the-box features were added which can be used directly. In AEM as a Cloud Service most new features are directly usable, not requiring (or even allowing) customization.
And as corollary: The older your code base the more customizations, and the harder is the adoption of new features.
As a SRE in AEM as a Cloud Service I work with many customers, which migrated their application over from an AEM 6.x version. While the “best practice analyzer” is a great help to get your application ported to AEM CS, it’s just this: It helps you to migrate your customizations, the (sometimes) vast amount of overlays for the authoring UI, backend integrations, complex business and rendering logic, JSPs, et cetera. And very often this code is based on the AEM framework only and could technically still run on CQ 5.6.1, because it works with Nodes, Resources, Assets and Pages as the only building blocks.
While this was the most straight-forward way in the times of CQ5, it becomes more and more a problem in later versions. With the introduction of Content Fragments, Experience Fragments, Core Components, Universal Editor, Edge Delivery Services and others, many new features were added which often do not fit into the self-grown application structures. These product features are promoted and demoed, and it’s understandable that the business users want to use them. But the adoption of these new features would often require large refactorings, proper planning and a budget for it. Nothing you do in a single 2-week sprint.
But this situation also has impact on the developers themselves. While customizations through code were the standard procedure in CQ5, there are often other ways available in AEM CS. But when I read through the AEM forums and new blog posts for AEM, I still see a large focus on coding: Custom servlets, sling models, filters, whatever. Often using the same old CQ5 style we had to use 10 years ago, because there was nothing else. That approach still works, but it will lead you into the customization hell again. Also many in violation of the practices recommended for AEM CS.
That means:
- If you want to start an AEM CS project in 2024, please don’t follow the same old approach.
- Make sure that you understand the new features introduced in the last 10 years, and how you can mix and match them to implement the requirements.
- Opening the IDE and start coding should be your last resort.
It also makes sense to talk with Adobe about the requirements you need to implement; I see that features requested by many customers are often prioritized and are implemented with customer involvement; a way which is much easier to do in AEM CS than before.
Things on a content management system 
it would be nice to have a sort of TLDR overview for best practices and tools for developers (or users). You also mention “coding should be your last resort”, all right but coding does have the version control (and rollback) advantage, which I feel UI actions lack.
I plan to write a series of blog articles with the intent to showcase what I consider good practice in 2024 (with a strong focus on AEM CS). But that might take a while.
Regarding “coding” and “version control”: I should have been more precise in the article 🙂 I actually mean Java code you deploy into your AEM instances, everything which lives in your “core” maven module. Custom components and styling is normally still required, the core components can only do so much.