Look, the ARM architecture specification is the reference, not some random Linux conference and neither some Power Point slides. It is the one place where ARMv8 is de facto defined.
It is very clearly stated there: "Features that are optional are explicitly defined as such in this Manual." So if it is optional, it must be in the ARMv8-A architecture specification.
So does your claim of optionality of AArch32 matches the ARMv8-A spec? I do not think so.
I think part of the confusion is how the reference uses the nomenclature, specifically what constitutes a "feature". In my understanding, an execution state is not a "feature", an execution state either supports or doesn't support a "feature". The reference itself doesn't seem to prescribe which execution states have to be supported. You can of course put your foot down and say "the reference doesn't say it outright, so it must be this or other way", but this kind of normative lawyering is not the most constructive thing to do. And no matter which interpretation you argue for it doesn't change the facts:
- There exist CPUs that implement ARMv8 while not supporting AArch32 (e.g. newer Apple chips)
- There exist CPUs that implement ARMv8 while not supporting AArch64 (e.g. ARM Cortex-A32)
- Future ARM high-perormance cores are dropping AArch32
In fact apps for AArch32 execution state do have some advantages when it comes to memory footprint, when they are compiled for T32 - which all Windows ARM32 Apps are.
Which might be relevant if you are running an embedded system, but for general computing? Like those extra 5-10% will make any difference. The performance benefit of Aarch64 is much more relevant than saving couple of bytes...