exactly. as load / save time is generally fine for the install i play from, but not for the dev install. and the less you have to allocate / process, the faster things will be
so memory optimisation can help improve loading times, thus squashing two common complaints (too slow, too much memory).
same with smaller dll/exe vs code optimisations as yes the code might run faster but if it cannot fit in the relevant caches in a machine, it'll need more paging and thus be slower compared to a smaller block of code which is slower but doesn't have to be paged out. and a smaller dll/exe is going to be quicker to load on program startup as well, but then loading lots of smaller dll can take longer than loading one large dll/exe, so it's all a balancing act.
alas it's never going to be clear cut, unless something is directly allocating a massive buffer and it's found to not be needed, or like the jtfe playlist copy in my prior post which could save anything from a few KB (which is still a saving) to a few MB depending on the length and number of playlist entries. though what it saves generally pales in comparison to what is used with modern skins or large libraries, not that i've not wanting to save potentially a few more MB.
so when it comes to memory, there's a limit to what can be reduced and it's not like we're just using it for the sake of it as-is. yes 5.x (and later versions, typically 5.3x+) use more than a 2.x setup (and how much will vary depending on the OS, plug-ins, etc) but most of that stems from unicode support (double-byte vs single-byte, which could have been dealt with by translating to-from UTF-8 but that can be messy and slower) and by using native unicode functions on XP and up, we gain some performance back as most non-unicode functions are translated to unicode ones by the OS (if i'm remembering things correctly).
plus, it's often forgotten that as a user's library grows, it's going to use more memory, so over time, Winamp will be using more just from the act of being used. that is often forgotten when doing old 2.x to 5.x comparisons i've seen.
and bug fixes and API improvements, etc have their place in better / fixed implementations can save resources or do things faster (having to use more to achieve it at times). so it's all about providing a rounded development experience and what that imparts onto the software being created, so you cannot focus on one thing solely (though can for bits of time) to achieve faster, smaller, stabler software i.e. a better Winamp.