thanks for humoring me 
what I understood you claimed in the call is that for āintermediateā use cases we could always use consensus, which provides stronger guarantees. my claim is that same argument is also valid for the use cases that fall into the ābest effortā category, so essentially what I was asking for is: do we have compelling use cases for not just doing consensus?
a bit more context for this question is that we are now thinking (or at least I am!) of inter-kettle comms as separate from the āSUAVE Chainā, ie where the code of the smart contracts lives, which does require consensus. so this is two separate consensus protocols, which begs the question of whether we can do just one. if we just have consensus for inter-kettle this seems more feasible that if we have both consensus and best-effort.
Iād love to learn if you/others are also thinking of inter-kettle comms as separate from the chain because maybe Iām missing something here and youāre indeed thinking about the same consensus (but in that case I donāt get how we can have a part thatās separate and thatās ābest-effortā).
finally, another point is that I wonder how much potential āTEE-enhanced richnessā weāre leaving on the table by us just considering these two models. as you point out running (whichever model we end up choosing) inside the TEE gets us some properties for free, like no byzantine safety violations. but as @socrates1024 pointed out TEEs still leave open byzantine selective messaging (which is also not equivalent to a crash fault). altogether this tells me that the threat model being different than the usual one might make us want to think deeper on what properties we want and how the tradeoff space is deformed by the use of TEEs. (I do get your point on āwe have consensus protocols that workā though 
).