One of the things our team has been told is that "We have to decide for ourselves what is clean and what is not". This has proven to be very unhelpful and not factual.
The truth is: there is no mystery as to what constitutes clean extensibility. SAP is actually surprisingly clear on this topic.
Consider the following diagram, which you've probably seen before:
Here we are considering primarily the on-stack section.
What are the tiers?
The definition of Tier 1 is all your developments that use only released-for-cloud objects, which makes those objects clean and therefore upgrade-safe.
(Objects that are released for cloud are guaranteed by SAP to have a stable interface, hence anything that uses them is guaranteed not to break in an upgrade).
Tier 2 is just a way for you to mitigate the cases where SAP may not have provided a released object, so you create a (temporary) wrapper as a workaround.
So, for example, creating a table that only refers to released data elements, is tier 1.
Creating a table that uses data elements that are not released would be tier 2. (Which is a bad example, because you would in that case probably just create the data elements yourself).
Just creating a table or other object does not suggest Tier 1 or Tier 2; it's whether the object uses released objects or not that decides in which tier it is.
A better example is if you create a CDS view: There, it is more likely that you might have to rely on some view of SAP that is not released. In that case, the recommendation is to create a wrapper around the unreleased object, mark the wrapper as released for cloud, and use that in your CDS view. That way, your view remains clean (Tier 1), but the wrapper is in Tier 2.
Then, if and when SAP releases something you can use to replace your tier 2 object, you retire your wrapper and swap it out with the released object.
Using this approach, you reduce the risk that you are creating objects that might cause issues with upgrades by making it easier to keep track of the state of "cleanness" of your system.
Tier 3 covers everything that SAP says you must not use, like Dynpro, WebDynpro, unreleased BAdIs, etc. But this is anyway more applicable to people who are migrating developments from an old system, such as in a brownfield scenario. In a greenfield scenario, by contrast, you will most likely avoid creating such developments to begin with. In a brownfield scenario, the idea is to progressively retire all your Tier 3 developments and replace them with Tier 1.
In the case of side-by-side extensibility, where you operate outside of the S/4 system or "off-stack", you can only consume released APIs anyway, which means there is no risk of breaking something in an upgrade, so that is clean by default.
What a released-for-cloud object is
To be clear, this is what we are talking about:
This is what you see when you go to the API State properties of an object that is released for cloud development.
When you make use of the "ABAP for Cloud Development" language version (a.k.a. "ABAP Cloud"), the compiler checks whether the objects you use have been released for cloud and will prevent you from compiling otherwise.
This prevents you from accidentally incorporating non-released objects in your code.
You can tell if an object uses this version of ABAP in the properties of the object:
If you set this language version on a package, objects created in that package will by default also use it, but you can override this per object to use the "Standard ABAP" language version, which would be the case for a wrapper object.
How this ties in with AEM (SAP Application Extension Methodology)
In short, it doesn't, really.
This is another rabbit hole we've been led down, believing that AEM is somehow supposed to help us identify what is clean core. But that is not its purpose.
AEM is a methodology that helps formulate an approach to deciding what technologies to use to fulfil a requirement. But the assumption is that you already know what is clean and what is not, and that is what I try to convey in simple terms above.
Bluesky
