Well, as I have shown in my style, this all isn't necessarily true:

I also have asked you before, to point out boilerplate code in my codes — turns our, you just names every code, that you don't immediately understand as such.

My codes do not contain any. They contain declarations that define the interactions and implementations that goes along that. Explicit separation of concerns.

boilerplate code is code that needs to be set up but has no domain value — not quite the way I code.

if you have objects with 14 properties, I'd advise you to split them into sub types anyway, just as I do here with the meta object: https://gitlab.com/vikingosegundo/items/-/blob/main/ItemsModels/Models/TodoItem.swift

to add an changeable property, one case declaration is needed, one implementation for that case statement in alter method, one parameter added to the private initialiser and all calls for that need the property added. if you use stuff like multiline cursors this is done in less than a minute and the compiler leads through all of this.

A coder can also write 1.5 tests/minute, like here: https://gitlab.com/vikingosegundo/items/-/blob/main/Items!Specifications/TodoItemSpecifications.swift

So how exactly is that expensive for the developer?

About swift evolution process: it must have a reason why even Chris Lattner does not participate in that anymore. https://devclass.com/2022/02/22/chris-lattner-leaves-swift/

My take away: it isnt about easiness for the coder — it is about simplicity for the compiler — and immutable codes are always simpler than mutable once.

I would actually argue that none of the premisses of your article holds true.