They were initially moved to system.properties for the following reasons:
Why were these moved to system.properties instead of portal.properties?
Liferay modifies the web.xml of every Liferay plugin WAR to include a reference to InvokerFilter and causes InvokerFilter to be used on every request. This is still true in master.
It's possible for a request to something other than Liferay to cause InvokerFilter to run (for example, a request for a theme resource contained in a theme WAR) before Liferay is initialized. When it does this and InvokerFilter calls any methods on a class that has a static initializer referencing PropsUtil, a class initialization error will occur. Subsequently, every request throws the ClassNotFoundException, which makes pretty much all of Liferay unusable.
If you attempt to restart the server to address the issue, it's possible for a different request to cause the same problem again, forcing yet another restart. You have to keep doing this until you finally get lucky enough for nothing to make a request to Liferay until Liferay has initialized.
The simplest way to address this was to switch to SystemProperties, which is partially initialized when the code is called and is fully initialized with the values in system.properties and system-ext.properties once the portal is initialized.
There is still a bug associated with the approach (if the first request goes to a plugin, it no longer uses the value specified in system-ext.properties, and to work around it, you actually have to specify things via -Dproperty.name=property.value properties), but at the time, it was preferred over moving the static initializer block.
All these challenges would need an additional implementation in order to be able to create a UI for it. That's the goal of this subtask