I guess if you think too much about what is essential to the Scrum you will end up thinking about what is essential to you project. That would be the natural course if we are using Scrum as a tool. It’s hard to just think about what defines Scrum, or to state what cannot be missed. The reason is that this thinking directs us to think in terms of satisfying the process instead of the project. I like the “ask the team + deliver often + inspect & adapt” trio. Your post seem to revolve around those elements too. At the end what matters is, like you say, delivering reliable software, isn’t it?

I find particular important to communicate what is essential to Scrum to teams that are doing some form of Scrum and need a reference to aim towards. Staying in the practice is often revealing of the principles and values. When the principles and values are second nature, then I am free to think only about the project.