A smaller main sfs is only desirable when you are loading/running everything from ram. For that perhaps using woofCE to woof your own configuration is more preferable over that of looking to remaster to downsize. Woof is relatively simple to use, but is quite time consuming (more of a run overnight type task, and where when unfamiliar you may end up having to do multiple runs (subsequent runs do tend to be quicker however due to already having downloaded the relevant files/data)).
A factor to consider is that running in ram uses more ram than not running in ram. If for instance the main sfs is 500MB and averages 50% compression, then if all data blocks are at some point read during a session then that might eat around 1.5GB of total ram .. the 500MB of (compressed) sfs content, and the 1GB of non compressed data that had been cached.
A alternative is to run without copying the sfs into ram. When the sfs is compressed using a fast decompression method such as lz4 that can actually be quicker to read/load than direct non compressed loading. Read half as much from disk and decompress it to twice that size ... compared to reading twice as much 'ready to go' (non compressed) data from disk. That way you'll find that it uses less total ram than what running-in-ram uses, leaving more ram available for other things. Yes the first time a program is run it will have more of a lag to start compared to if already loaded into ram (where it just has to be decompressed into cache), but subsequently more often there's no difference in program launch speed as both methods have the program already cached.
I use Fatdog, and my 'remastered' main sfs for that (fd64.sfs) contains around 2.5GB of non compressed sized content, that is around 1GB when compressed using lz4 (mksquashfs squashfs-root fd64.sfs -comp lz4). Without that being loaded into ram after bootup it uses around 250MB of ram space whilst operational (and boot) speeds are more than acceptably 'quick-enough'. In that context size doesn't matter. Much of that content likely never gets read/used during a single session, is redundant, but in other sessions those prior unused elements might be called upon/used. Such as gparted that is quite a large binary filesize, is infrequently used, but handy to have it ready to go when needed.