We don't know "how wards work", but we can speculate on how they're implemented and one person's speculation could be completely different from how it's actually implemented. We can speculate on how "instanced housing" vs "instanced wards" could be different.

The difference between "instanced housing" and "instanced wards" (what we have now) is that there would at least be faster server calculation time. For "instanced housing", you'd only have to calculate and update the clients for object positions for the single house and ornamentation, where for "instanced wards" you have to calculate and update object positions for 60 houses (* max yard ornaments). It's an improvement, but you only see the gains when the number of houses & their ornaments (including colors and types of exterior walls and fences) go over a certain threshold. Less things to calculate = faster calculation = less memory used = more cpu time for other calculations. Batching smaller calculations improves performance in any system, this is why threading is preferred for multitasking vs process based multitasking - threads are lightweight; using smaller portions of cpu (a few lines of code or a few hundred lines of code) and memory at any one time vs a large process that runs ALL the process code (millions of lines of code) during it's required calculation time increasing memory usage and cpu usage a TON during that same time frame. As far as long-term storage (hard drives), that's cheap, plentiful and relatively fast so that shouldn't be a problem. The problem comes in loading that into and out of short-term storage (RAM) during the required calculation time frame. Combine that with everything else that needs to load into RAM and you start seeing the performance issues with large housing wards. In the end, we don't know how they handle the instanced wards but assuming that every region and housing is handled by the one server you're on that's a TON of stuff that needs to be in RAM and needs to be calculated and sent to clients to be updated. Another thing that could improve housing is a set of servers dedicated to instanced housing (including instanced wards for housing). However, that's a fairly expensive solution to the housing problem - throw more hardware at it is always more expensive and probably doesn't make financial sense for SE right now (remember they also have to pay for all the data that they transfer to the clients, which in a game this size is easily hundreds of terabytes per month if not petabytes and that's expensive AF). If they're already dedicating servers to housing, they may be using servers with fewer resources to save money or housing as implemented is a really heavyweight subsystem and the only solution there would be to rewrite the subsystem.

Now asking for "instanced housing" as the same as "instanced dungeons" is asking SE to dedicate servers for housing. Do they do that now with "instanced wards"? Are wards instanced like dungeons, raids and trials? Does anyone really know or are we just speculating? Unless you have someone from SE saying "this is how we do it", it's all conjecture and is most likely a worthless suggestion. The only thing that we know "instanced housing" would do is decrease processing time and assuming that the information needed to calculate positioning is only held in memory long enough to update clients would prove useful only by making those calculations lighter weight.