The Verilog code for an acceptably efficient DRAM controller would be larger and more complicated than the Verilog code for the entire current system put together. It's not a good fit for a project that seeks simplicity.
The Spartan 6 FPGA can have DRAM controllers built in as a hard block, it won't use up any FPGA gates.
The issue is that you then need to interface this to the CPU, modern DRAMs like to transfer bursts of several words and you need somewhere to put this. The obvious target is to one line in a cache but as the linked email states a cache controller for the Oberon RISC would be more complicated than the designers wanted for the project.
Why do you care about efficiency? Use all your block rams for a cache to mitigate the dram inefficiency, and use the simplest possible controller. They can be quite simple, really, see this one for example: https://github.com/fpga-logi/logi-hard/blob/master/hdl/inter...
That's still more than twice as long as the current largest module, and now you need to add caches to the system. (To be clear, I'm not involved in Oberon's design, I'm just explaining the reasoning as I understand it.)
Understandable. OTOH, it brings such a design much closer to the realistic hardware, making it a more valuable teaching tool. Understanding the cache is important.
A quick googling found this: https://lists.inf.ethz.ch/pipermail/oberon/2015/008083.html
But I don't really understand the explanation. Does DRAM need software support? Would performance just be unacceptable?