As much as I support Right to Repair and end-user control, and also don't particularly like some of the ideas coming out of the security side, I think you're right. The statement you quoted is very much not true, both here specifically, and also in general.
In optimal conditions, it seems to me that you always have a trade-off - "security or utility, pick one". If it often looks like you can get both, it means both currently are bad (er, suboptimal, to be polite). In the limit, the most secure computer is an inert rock: there's no way an attacker can break in and exploit it for anything. The flip side being, of course, that it's completely useless for the legitimate operator too.
Coming back from the theoretical extremes, straight to real-life systems:
> software locks that make benevolent repair harder can also make malicious tampering (to hardware and/or software) more difficult as well.
This is true and self-evident, IMHO. A security system (whether hardware or software) can't reliably tell who's accessing it and why. The goal is to only have the right people use the device/program for the right reasons, but such discrimination can only be achieved by proxy. Auth (both kinds) proxy for "right people", and "right reasons" is just assumed.
I highlight the latter because people can be "hacked" too. You can imagine having a magical system that can correctly authenticate and authorize users 100% of the time, defeating any impersonation attempts (including attacker having unfettered physical access to the system in question) - but that system is still highly vulnerable, because the attacker can confuse, gaslight, scare or threaten the authorized user into self-pwning. The badly but memorably named "Self-XSS" attack is just the most trivial example.
Point being: once you correct for bad UX and shitty corporate practices, dealing with risk of self-pwning (and, related, the risk of misinformed or accidental misuse) will always make security trade against the capability of the owner (or the agents of that owner, such as a repair shop). And then it gets much more complicated when the device has multiple owners with conflicting interests, and/or there are additional stakeholders, such as the general public[0]. Balancing those conflicting needs often requires not just legal, but also technological lockouts.
All this is why I don't find "but security!" as a valid argument in itself. There is such a thing as too much security. Balancing conflicting needs of the owner, the other owners, additional stakeholders and a sense of fairness in general, is an exercise of trade-offs. Often you need to sacrifice security to achieve fairness. Conversely, security features can also be used unfairly, as a form of abuse. DRM technologies, for example, are abused quite a lot - and Right to Repair is, to a large degree, also a fight against security measures that favor the vendors at the expense of end-users and society at large.
--
[0] - A modern car, for example, may be owned by the buyer, but thanks to intellectual property laws its also partially owned by one or more companies, and you have both governments and the public in general as stakeholders - all of which have mutually conflicting interests. E.g. you may want to redo the entire UI of the car - but you'd need access to IP the vendor doesn't want to release without a license, and it's way too expensive to them to license those secrets to you individually. Then, this would fly against homologation procedures, and the government ain't going to change them just for you. Meaning your mod can't go through processes establishing road-worthiness, safety and emission standards - all of which is important for... just about all the stakeholders, perhaps other than you.