"Never attribute to malice that which can be attributed to stupidity."
My guess, after years of working with Samsung's poor-quality platform software and multiple runins with their utterly piss-poor configuration management processes (as in, the Korean divisions at Samsung Mobile don't seem to have any, as evidenced by numerous situations during the Superbrick fiasco):
Samsung probably put this into the RIL library to facilitate modem debugging. e.g. the modem can read/write to /efs/root/ in order to make it easier for a developer to track state changes of the modem or whatever. (Why do this instead of using whatever debugging functions are built into the modem such as maybe JTAG? This is probably for late-stage development where they wanted to test finishing touches on the modem using final hardware and the modem's debugging functions weren't physically available.)
Keep in mind that, based on the reverse engineering effort, Samsung *intended* this feature to only access files within /efs/root/ - the EFS partition is specifically reserved for device-specific state and calibration data (most notably the phone's IMEI is stored in the EFS partition, and with the exception of some miscellaneous other config data such as MAC addresses for wifi and BT, it's almost entirely for modem-related items. I may be wrong about the MAC data, I'm a bit rusty and haven't poked around at my EFS partitions in a long time.) It's only due to a screwup (lack of sanitization of escape sequences such as ../../ ) that someone can in theory access files outside of /efs/root
So at some point, Samsung probably removed the corresponding components on the baseband firmware side (no one has yet to confirm anything on the modem side that sends these commands, nor has anyone caught any of these commands being issued - the behavior of the library was verified by injecting extra commands with a kernel patch in the driver between the modem and the library), but someone forgot to remove them from the RIL library on the applications processor side. Forgetting to remove dead code and/or leaving epic security holes in place (remember that in late 2012, someone realized that Samsung left a world readable/writable device node that effectively mapped all system memory to that device file - allowing anyone to read or write any part of memory. For more, do a Google search for "exynos-abuse" ) is pretty typical for Samsung.
As to my experience here - I was one of the Cyanogenmod maintainers for the Exynos 4210 (I9100, I777, N7000) handset family, and also did some work on 4412 devices (primarily the Note 10.1 - GT-N8013) throughout 2012 and the first half of 2013. I'm 90% retired from working with Haxxinos these days and was (along with the majority of the rest of the Exynos maintainers) one of the people who left the project to start Omni after the Focal relicensing attempt fiasco.
An interesting question is - what architecture is the XMM626x's baseband processor? Is it custom or an ARM variant making it easier to analyze the baseband firmware itself? More than two years of working with that family of devices and I never personally looked in detail at what was running on the baseband side.
