I wasn't sure how much your ideas deviated from mine, which I why I said "clarifications"; but you're slightly incorrect. DevOps isn't two philosophical ideas. It's lots of things, and all those things are the methodology. There are many books, podcasts, blogs, conferences, etc that go over all of the things DevOps is. It actually has little to do with tools or software, even though that's basically what it was created around. It is a general methodology, and you pick how you implement it. You can even apply DevOps to non-software processes.
Look at it this way: The Toyota Production System isn't about cars. It was developed specifically to produce cars as well as they could be, but it doesn't address "car problems"; it addresses business problems, production problems, workflow problems. It applies methods as practices in ways that are specific to the production of cars, but you can apply the principles of TPS to things other than building cars (as we do with Lean).
DevOps is comparable to TPS (well, Lean), but for software instead of cars, and it borrows from other systems, and it has a few of its own ideas specific to software.
> Along the way, I specifically denounced the idea that DevOps is a single methodology, or that some tools are more DevOps than others, or that DevOps makes prescriptions about what you should do. Those are all things that you immediately advocated.
I advocated using containers because they help reinforce DevOps principles better than alternatives. You don't have to use them, but that doesn't make them un-applicable to DevOps. There are different levels to DevOps, and one of them is "practices": particular ways of doing things that DevOps encourages, such as Infrastructure as Code, Immutable Infrastructure, Heterogeneous Environments, Continuous Integration & Delivery, etc. Things that containers are more useful at accomplishing than, for example, VMs.
You don't have to use Kanban to run a car production line. But it's more TPS than the alternatives.