While you are mostly correct (at least to about ~95% of cases - many people really do write horrendously inefficient code), its not true in all cases. There are valid cases why software might be more resource intensive now then before:

• various security & hardening related features might make stuff more resource intensive while making applications more secure and harder to exploit/attack
• more robust range checking - more or less directly related to the point above, you can prevent undefined or directly exploitable application behavior by stricter range memory usage checking at cost of some processing & memory usage - an ideal program of course does not need this and would run faster and with less memory usage without it, but humans hardly write ideal programs on a regular basis
• localization and accessibility - a hardcoded-to-English app without accessibility would be of course be a bit faster, but harder to use for people that are not native English speakers and/or have various disabilities
• bigger screens and advanced graphical/usability operations - modern computer screens are much larger than before, meaning larger bitmaps, larger framebuffers, etc.; applications might also opt to use transitions or other visual cues to make the UI more fluent (eq. stuff animates to place vs just blink in place without any transition) which can again cost some performance
• optimizations - programs can opt to actually make use of all that available RAM/CPU power to do CPU/memory usage trade-offs that actually make the application faster at the cost of bigger resource consumption - of course there should be a way to dial down or outright disable these optimizations when running in a resource constrained environment
• introspection and debugging information - you can make your data structures slightly bigger by adding additional information that is not strictly needed for your application, but which can be used by other tools to either make better use or your code (if you are a library an example can be the GObject Introspection, which can generate language bindings automatically, as an example) or might aid with application debugging (GTK inspector can be seen as an example, or improved crash tracebacks, etc.)
• portability - an application written for a single combined software and hardware platform can make a lot of assumptions that improve performance - at the cost of making the application very hard to port to other platforms; a multi-platform application needs to make much less assumptions, needs to do many checks at runtime and often uses slightly less efficient techniques/APIs that are platform independent in place of faster but platform specific ones to aid long term maintenance