> Prioritising individuals and interactions over processes and tools makes sense because it is easy to adapt and modify software tools, and because software allows abstracting out any form of repetition without needing to make it a process.

No, it makes sense because the processes and tools don't work if they don't work with the individuals and their interactions, and that's true in much wider domain than software development (it's true of any highly skilled, or even more generally labor-supply-constrained, work, where you can't easily replace the workers with ones that fit the preferred process; it may be applicable even more broadly, since sense of ownership of process can be a morale and productivity booster), so the process and tools must be subordinated to the team rather than vice versa.

> Prioritising working software over documentation makes sense because source code is understandable in itself to a much greater extent than physical artifacts.

No, prioritizing the production objective over supporting artifacts makes sense because of the fundamental nature of an objective. That's just as true when the production objective is not software (doing so will result in different levels of documentation and other supporting artifacts for different production objectives, sure, and software may often have lower documentation needs than many other tasks, but the prioritization isn't about do less documentation, it's about “do only, but still.all of, the documentation that has utility outweighing cost in support of the production objective of working software”.)

> ... software allows abstracting out any form of repetition without needing to make it a process.

This is backwards. Software enshrines the repetitive business process and (hopefully) automates it as much as possible. This is happening regardless of whether that business process was defined before the software was implemented.