Dear Yuli Barcohen,
I'm almost exhausted by this topic. The patch is only an option. It is just for convenience and consistency of environment variables between boards. It has nothing to do with any philosophy.
If the above mentioned board designer chooses to use a boot block, he/she selects flash which is protected by default.
Bootblock and environment is protected again just after the unprotection. Please check the code.
If U-Boot must automatically change this behaviour,
It is not mandatory. It is an option again.
why to use such a flash in the first place?
People do mistakes. And to currect it on software is easy. Changing hardware is very expensive and time consuming. Although I come to think changing software is more difficult sometimes because of this issue.
Regarding the implementation, unprotecting the flash on U-Boot's start up requires exactly the same operations as implemented in the flash_real_protect function (which is controlled by CFG_FLASH_PROTECTION) so IMHO the same function must be used for automatic unprotection too to avoid code duplication though I agree with Tolunay that defining CFG_FLASH_PROTECTION and calling "protect off" is the way to go.
flash_protect calls flash_real_protect if CFG_FLASH_PROTECTION is defined. It is not a code duplication. If flash_init tries to directly calls flash_real_protect without CFG_FLASH_PROTECTION. It produces compile time error because flash_real_protect is not defined without CFG_FLASH_PROTECTION. I don't think such dependency between configuration is a good implementation. If you still don't like the implementation just send a better patch.
Again, I don't really like to mess up with you because of some philosophy or spirit. Software engineering is just for convenience after all.
Best regards, Sangmoon Kim