In C++ you will use also use casting, there is no difference to blueprints. The difference is that in C++ you only have code, so casting to another class has no impact, but in blueprints casting will lead to having a hard reference to what you’re casting to (same as if you would have an object reference to an object or if the interface has a reference to that object). All assets that your blueprint is hard referencing will be loaded into memory as soon as that blueprint is loaded into memory (generally speaking all assets that an asset is hard referencing will be loaded into memory as soon as that asset is loaded into memory). That means you should avoid casting to objects that contain static meshes/materials. As long as you’re only casting to blueprint classes that contain no static meshes/materials/sounds,… there is no problem using casting.
So the problem is not casting but hard/cross referencing different assets and the resulting high memory usage and load times. So if till now you have never looked at your blueprints in reference viewer and size map, then you will have some refactoring before you if you want to fix it.
Generally I currently use C++ for two reasons
(-) the functionality is not exposed to blueprints and either cannot be exposed to blueprints or would be too bothersome (e. g. the whole AI perception system, gameplay ability system). This then also leads to having your base classes in C++.
So if for your save/load system you need functionality that is not available in blueprints, then yes you will need C++. If you need to do a ton of things on tick for your save/load system, then again C++ would be a good idea. Otherwise blueprint is much faster for prototyping and if you later on see that you need extra performance, you can always shift some functionality to C++.