this reads like science fiction to me - all quite different to the work culture that i experienced; are there any examples of real companies that practice a significant subset of these principles?
The only one that I know is not universal is "Healthy oncall".
Going somewhere where most of the boxes are not checked, and the leadership thinks that it's OK, looks only reasonable to me if the pay is exorbitant, or the experience is huge and unique, so that you can leave in a year and have a better position in a good company.
I can elaborate further.
The main sticking points I experience are "Cross functional collaboration". There are entire categories of work where this isn't really easy/feasible. The actual users are not available, so you must use a proxy. The opportunity for improvement is where they developers have some say in how the proxy acts (can everyone see the same data they work on, is there an opportunity for feedback, etc).
Things like "functionally complete" vs "ready for production" require a strong management presence for the development team. IMHO, the easiest way to solve this is by not having a distinction between the two. Don't make it functionally complete before it is ready for production. This requires breaking down the work differently than a lot of organisations like. You need a strong lead/dev manager who will take high level items in the backlog and break them down into vertical stripes of functionality that can be delivered incrementally. It can be quite a political problem, but this is probably the place where a lot of organisations are going to run into trouble.
Another common problem (especially with smaller teams) is the lack of career progression. This should be obvious when you start. If the group is small and not geared for growing rapidly, you will not likely get a promotion. It's simple math :-) No spots for promotion means no promotion.
There are a couple things on this list that I would dispute, though. Celebrating taking initiatives: there are pluses and minuses here. Some developers just do crazy stuff. Other developers do nothing for fear of criticism. It's not really the case that you want to have people indiscriminately taking initiatives. It's more that everyone should have opportunities and everyone should be encouraged to take those opportunities occasionally. There is always a balance -- going too far one way or another is really bad for everyone.
CI and CD deploying directly to production: Sometimes a good idea. Often not a good idea. In reality, you want a human (or some humans) making the call as to whether or not something should go. If you make it an automated part of the process, then people will put blocks earlier in the process to ensure that customers are not surprised, or stakeholders get a chance to OK the final product, or deployment meets marketing schedules, or there is a final quality check for risky work. What often happens is that these blocks become adhoc rather than part of the process. Usually it is better (in my experience) to always have manual deployment (although it should always be easy to the point of triviality to do it).
I think how I would take this list is more as a set of questions you can bring with you on your job interviews. How does the company handle these things? What are the opportunities for improvement? How eager does the organisation seem to implement these improvements? If you join a team and you have significant friction in many areas, it's basically too late. You should probably start looking for a better place to work.