From the perspective of firmware, an OLPC system uses 3 major parts: LinuxBIOS, OF, and OS (usually Linux, but it can be Windows). At system startup, LinuxBIOS initializes the system and invokes OF. If it were a SPARC system, LinuxBIOS would have been called "POST". Afterwards, OF is accesses the boot media (Big NAND flash, wireless, or USB) and boots the OS. I do not know for sure if OF or LinuxBIOS present the interface to the OS when it runs, but I presume it's OF.
So, the issue is that although I obviously do not know the details, the OF appears redundant. Firstly, after-boot firmware interface is completely unnecessary for OLPC. The ACPI in case of Intel is a way to avoid publishing details about CPU frequency and voltage mangement for them. But on OLPC, these things are presumably documented. For crying out loud, this thing runs on a Geode! Going further, OF is used to boot things. That is good, but it's not as if these bootstrappers could not be written, say, in Java. They are separate programs plugging into LinuxBIOS (or taking over). Booting over the wireless is something that Etherboot could do just as easily.
The OF is not cost-free. It uses space (in flash and in RAM). On SPARC OBP runs into the region of 200 to 500KB. The may be not entirely trivial for OLPC. Also, it takes some time to initialize, and it runs slowly. And finally, nobody can ever fix anything in it... except Mitch.
I just can't understand what OF brings to the table that advances the goals of OLPC. A unified way to select a bood device from the "ok" prompt, perhaps? Seems somewhat valuable... for a general purpose platform. This is some kind of a mystery.