The metaphor is wrong. As a normal user you would never come into contact with these files.
The "gaping hole" is actually in a fenced-off area with keep-out signs where nobody would wander in by accident.
I create a file in my WSL home directory, and want to edit it in Sublime. So I google "where is the WSL home directory stored" and get `%LOCALAPPDATA%\lxss`. I plug that into WIN+R, and get the files in explorer. At no point was I stopped or even warned.
The reason is clear. WSL is grafted on to Windows, and has low priority. The windows shell and filesystem teams are currently not working to improve integration from their side (at least not publicly visible).
The shell people could put up a banner in explorer, like you got in Program Files in previous windows versions, that you shouldn't edit these files (e.g. via desktop.ini). From the filesystem side, it should be possible to make the kernel know about WSL and prohibit writing to those files from windows.
WSL could also have been implemented with an image file, instead of individual files in `%LOCALAPPDATA%\lxss`. The reason they did it this way, I believe, was to keep open the possibility of future two-way-integration. But this would mean change-listeners not only in Linux land, but in Windows-land... which again would need deeper integration from other groups at MS. I suspect once WSL has proven itself a bit, they'll add full transparent two-way-integration, i.e. you'll be able to edit lxss files from windows one day.
And how would the shell team put up a banner in Sublime?
If the kernel prevented these files from being written to, how would we install the distro in the first place?
Could, should, might, may. Yep, there are 100 ways in which some things could, and may yet, be done, but these choices were made for hundreds of sound reasons.
We're still working hard on WSL - lots of improvements in the pipe.
I just wanted to make clear that the parent comment is slightly hypberbolic.