We may have different idea’s on what “basic” is 
I’m not sure that’s the case, the data held in RAM by emonhub uses very little space, however the size of the device payloads, the number of devices you have, the frequency at which they post and of course how long you are without a network will all determine how much room you need whilst how many things you have going on on the Pi will determine how much RAM is available, as long as you are mindful of this you should be able to have what you want.
For example the emonPi image is running emonPiLCD, mqtt_input, nodered, openhab, lightwaverf and mosquitto whether you want them or not, you must have Apache2 to run emoncms, so by simply using http to post to emoncms you can shutdown all of those services (if you don’t need the emonPi display) which should give you plenty of scope to run a desktop, especially if you only need a browser console.
(sidenote - Are you aware that you cannot access the HDMI socket on an emonPi due to the case?)
Can you clarify what HW you are using? You have said “I decided to settle for emonpi.” and "I got a RaspberryPi with a 4.3 480x272 lcd " so I’m unsure if you have the emonPi or have another Pi + LCD or both, if both, are you planning on having just one or both set up?
It works very well, I haven’t heard of any failed SD’s for a significant time now, but it has it’s limitations, personally I like emonhub on a SDcard with a read-only fs, but always install emoncms to a Pi with a hdd or to a cloud VM, but that’s just my preference, I guess many more users use the emonSD for emoncms than use hdd.
The main difference in emonhub versions is that the original isn’t geared up for mqtt, the way mqtt is set up in the emonPi variant is VERY emonpi orientated and not so flexible, so you either do MQTT the way it’s done on the emonPi emonSD image or you don’t do mqtt, there is no generic mqtt options in either emonhub yet. The emonPi variant also uses named inputs rather than just node ids, but you only need to name your inputs once, so that’s no real big issue. However there are some bespoke interfacers that will only work with the emonpi variant to connect to modbus etc, so depending on how you are planning to connect to your devices may impact your options.
It’s pretty difficult to adapt the emonSD to your own requirements, so you either need to just go with it and accept what to have, or avoid it and do your own thing. You can chop and change it about, but whether those changes would survive an “emonpiupdate” or even cause compatibility issues is something you will need to deal with as it happens.
