Point 1 is dependent on the individual and often not the case. Especially in cases where the part that takes effort is figuring out the poorly documented syntax/api you’re stuck with for the task (extra fun with new components iterating rapidly and pinning the next version requires new scaffolding), you can read the invocation and the accompanying couple of lines of test code way faster than you’d mould them yourself. Which also translates neatly to point 2 (how efficiently can you in many cases ascertain the outcome of smearing the chosen bits on the cpu with easily digestible tests).

Also the emotionally laden appeal to "responsibility" is weak, as it glosses over the many cases where overspending resources on creating the thing would be the irresponsible choice.

> Point 1 is dependent on the individual and often not the case.

Not really. To properly understand code you must have a mental model of what it is doing. You need that model whether you are reading or writing the code. It is easier to build that model while writing the code than while simply reading it. To build the model while reading the code requires having the same understanding of the problem and the same approach already in mind, which is almost never the case for any moderately complex problem.

> Especially in cases where the part that takes effort is figuring out the poorly documented syntax/api you’re stuck with for the task

Reading LLM generated code does not avoid this, and in fact it is often worse since LLM comments are terrible at getting to the point.