I am unsure about how we are going to sustain a default threat model along with platform specific threat models overriding it. Although I agree that in the end it's the platform owner who decides their own threat model. So probably a security disclaimer print like what we have in OP-TEE [1] makes sense for TF-A as well so that silicon vendors/OEMs are aware of security guarantees.
Yes, absolutely, the config option for this should come with explicit warnings about the security implications.
I can't think of a way that this solution can work without platform specific hooks in the generic code. So if we are going ahead with this approach then I would suggest adding a platform specific S-EL1 authentication hook as well which you can define as a dummy describing the threat model consideration for your platform.
I think compile-time configuration options are probably the best way to differentiate this. I don't know what the exact best approach for combining this with some sort of verification option is -- I think that could be either platform-specific or it could be some generic mechanism. That would be easiest to decide once someone actually has a use case for that, so I'd say we just implement the base functionality needed for our use case for now and then whenever the next use case with different requirements comes up we can decide how to best extend it to allow for that.