You have hit on an old design limitation. (In my opinion all MCUs should have at least twice the RAM of the minimum Flash erase block size, either by increasing RAM or by lowering the Flash erase block size. But, that's another story.)
Back to your problem: Obviously, your EEPROM data aren't loaded into corresponding variables all at once, or else you shouldn't have a problem. So, you're using that one Flash page more like a mini-disk, and I think in this case there isn't much you can do (without over-inflating code, which already must be near its limit or else you would find that extra Flash page you actually need).
It would help to know what most of your data represents, but I'll give it a shot without it.
Other than going with a bigger chip, you could try these:
Optimize the code further so you may free one Flash page for scratch pad. Even carefully written assembly code can often be optimized down a bit several times. If you're not using assembly in such a small chip, you could rewrite the whole thing in assembly, and the problem will disappear (you will certainly free at least one more page).
Simple compression or even variable combination based on bit-size is one option. For example, a value up to 3 with a value up to 63 can share the same byte.
Choose most-used defaults for some variables, and not allow changes for them. Or, allow up to so many changes in all variables collectively. So, that one user may change any variable but not more than, say, ten variables total. Then you only save the changed defaults to the mini-disk (but you need to index things so you can know which is which).