One way of looking at RiscPkg is it's a (semi-)centralised archive of software like HENSA was. But it just happens to be designed in such a way that it can also automatically install. So if you really want to install everything manually, it's no different from downloading stuff from HENSA or the author's website. It's just a bunch of zipfiles after all. But if you would rather your machine took charge of installation then you can do that too. It just means a reduction in the higgledy-piggledy way software is packaged and distributed at the moment.
Remember that you don't actually lose much control over the current situation. Applications are still applications and largely self-contained, and there's nothing to stop you deleting a RiscPkg managed application. You'll just have the same consequences as now if other things depend on it - in fact it's better than that because the database says what depends on it. Even if applications are forced to be stored in a certain place (perhaps not the case in future) then it's no too hard to create link applications (like AddApp does in Resources:Apps) that you can keep whereever you like to run the program. And at the end of the day the package state is still visible, so if you really want to convince RiscPkg that version 99 of GCC is installed, you just have to change the database textfile. Whilst none of these things are recommended, in the same way that fiddling witht the inside of !Boot isn't, nothing is stopping you if you insist.