Like many optimization questions, the answer here is "it depends."
Having separate scenes for each version probably won't increase your game size by much, since the bulk of the storage usually goes to content both scenes can share via
sharedassets#.assets files in your built data (textures, meshes, sound & music tend to be the biggest hogs), so in many cases all that's really duplicated is the scene hierarchy. There are some caveats to this - in some cases using static batching will save a combined version of multiple meshes as part of the level file, for instance.
And when trying to combine scenes into one omni-scene, it's certainly possible to cram it full of so much alternate content that it has noticeable performance impact. As an extreme example, if every texture in the scene needed to be replaced with a snowy version, you might spend double the time you need loading the scene, pulling in twice the texture data (since Unity will typically load all referenced assets together with the scene), only to leave half of it unused.
Conversely, there are plenty of scenarios where the extra complexity of the combined scene would be trivial - maybe you're just swapping a few material & script parameters around. The best way to know for sure which case you're in is to profile it both ways and compare.
This also has to be weighed against the development cost of maintaining multiple versions of the same scene. If every time a level artist moves a tree, they need to save, load each alternate version of the scene, and make exactly the same adjustment in every one (or juggle multiple scenes at once), that starts to sap a lot of their time, and likely their will to keep iterating & polishing, as well as giving more opportunities for mistakes and bugs to creep in. So, a little inefficiency in the scene load, and some maintenance on the scene-alternate-switching tech, might ultimately be worth it if it helps you build & refine your game content faster.