High Performing Teams - is it a myth?

Suppose a team think they check all of those boxes, but they aren't delivering a fully integrated, tested, and valuable increment of release quality each and every Sprint. They operate very competently and efficiently, but only within organizational constraints and dependencies which they accept as being beyond their control. Are they still a high performing team?

This is a really great question! I agree 100%, whether a team is "high-performing" is always relative to how we define high performing.  

Thinking about this topic, Google's quest to find the composition of high performing teams comes to mind (their journey is documented here by Charles Duhigg, who also wrote about it in his book Smarter, Better, Faster - https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-it…) 

When Google studied what made some of its teams top performers and others mediocre, it found that psychological safety was incredibly important. This means that team members are comfortable taking interpersonal risks, and are thus comfortable giving feedback to one another and posing new ideas in a group setting.  In my experience, teams that are capable of having candid and productive Retrospectives tend to be higher-performing in general.  

I like your list!  I think you are right that it is a dynamic rather than a static list - there is not really a 'level' of performance described, above which you are 'high performance'.  I think the 'High Performance Tree' exercise was especially meant for modelling a vision with a team rather than as a performance measure.  It works well when the outcome of the exercise is a product of the team, as opposed to what Lyssa Adkins gave as an example. 

You also ask 'how would you approach a team believing they are perfect?' Jeff Sutherland addresses a similar point in this book 'Scrum: The Art of Doing Twice the Work in Half the Time' about teams in a 'happy bubble'.  I have to say I have little experience with this for long periods - reality will inevitably catch up such that the context will force the team to go from the static 'perfection' position back to the dynamic 'continuous improvement' stance.  You could try pointing out that thinking you have reached perfection automatically means you haven't reached it but as my sailing instruction mentor used to say: 'sometimes you have to let them crash the boat'. Perhaps find a not-too-destructive situation to crash?

Maybe it's just me but "High Performing Team" seems like an out of place term within Scrum. Wouldn't it be better to have "Highly Efficient Teams" as the label? To me, when I hear "high performing team" my mind immediately thinks that team will have a high velocity and always meet their goals. Considering that Scrum is not about the numbers and much more about efficiency, I think "Highly Efficient Team" is a better term to be incorporated. Many people who don't understand Scrum will look at a product that is being created via Scrum and see how long it will take and think "how is it high performance if it takes 4 months to get a simple program put together?" I've had that conversation a lot recently as I'm working to get my company on board. When I explain the efficiency aspect of using Scrum, our upper management is a bit more prone to grasp the benefit. 

The idea that a team is perfect is absolutely false. I am a guitarist and have played for over 20 years. I can perfect a technique but I will never be a perfect guitarist. Two of the most incredible guitarists of all time, Steve Vai and Joe Satriani, both attribute their awesome talent to 8-12 hours of practice on a daily basis. If you listen to them, you'll see just how incredibly talented they are; but they still practice several hours a day because they are not perfect. If a team is truly perfect, it is clear they are not open to inspecting and adapting to new practices and therefore they may become perfect at doing a specific technique but will never be perfect overall. Simple fact is you become better by not being perfect, you become a better team by trying new things and failing at things. 

I appreciate everyone's feedback. This question here was purely to have a discussion (in a way, philosophical) on this topic. 

I just saw a good Agile quote that I think works great here: "Agile is a direction, not a destination". The same can be said about high performing/efficient teams.

Since Agile is based on inspection and adaptation it's essential for any team to look at how they work and seek opportunities for improvement. As soon as you say "Everything is just perfect" you stop looking for ways to improve, so you become less Agile. Transparency also seems to be compromised as you are practically trying to hide potential problems, even from yourself.