Except that the wheels didn't fall off the phone. This lockup happens due to code proactively added by Apple. You are confusing three different issues: the design of the system, the legality, and how security should work. In this case, none of those three items align. This is Apple's problem - they chose the easiest option for themselves, not what would benefit customers legally, functionally, or by securing the device properly.
You are fundamentally misunderstanding the threat model. What is the exact threat that Apple is guarding against? Is it an evil maid attack planting new sensors, switched devices, someone's fingers being cut off? All of these require different mitigations - none of which for a general purpose consumer phone are to brick the device when upgrading.
Actual Leonardo: "Why do you want this? I have found upon much observation and reflection that those people of stout character who request Fizzbuzzium would be far better served with the presentation of the solution to an alternative problem that more closely describes the situation. Please find it within yourself to return to first principles, so I may remove the original first problem with quickness and zeal that you have not yet seen."
It looks like the file is replaced every write, too, which removes most of the hard use cases. It really seems to me that he could just use PyNaCl to encrypt the files and not have to bother with all the custom crypto. I don't know what the intentions and tradeoffs are, though, so I can't be sure.
You could make similar threat-model arguments as are made about FDE, but that's not really a good excuse when authentication would be technically easy in this case.
There are a tremendous number of other ways this could be implemented.
Authenticated encryption? GCM? XTS?
Salt the CFB? Guard against interblock attacks?
The crypto needs to be completely reworked. This is an asymmetric kek around symmetric encryption, which is done in many other projects.
Half-backed crypto such as this is worse than no crypto at all, as it lulls people into believing they are using a valid cryptographic system. But, the project implements (poorly) a subset of what is needed and pushes the rest into application code - but app writers don't know this and wouldn't know what to implement even if they know of the shortcomings.
Cryptographers see this all the time. People think they invented a new concept but only implemented a well-known design but did it incompletely and with well-known flaws in the crypto. Then, people defend the system, when it would be far easier to use better primitives.
