There is not really a "UX" reason for this—or if there is, it is a very limited one. The actual reason why dialog backgrounds are (by default) some shade of grey is because some designers thought that looked better.
In many early operating systems, dialog and window backgrounds were stark white. Obviously they were white on the original Mac OS, since it had only a one-bit black-and-white display. But that continued long after the Mac II added support for a color display:

On Windows, the default settings had a white background for windows and dialog boxes all the way through Windows 3.1:

Starting with Mac OS 8 and Windows 95 (other operating systems followed suit, naturally, and the precedent had already been well-established by previous less-popular windowing systems such as NeXTSTEP, DESQview/X, and Amiga Workbench), it became all the rage among designers to give controls a 3D appearance. You can already see the beginnings of this in the screenshot above from Windows 3.1—the button controls already have a faux-3D look. To complete the 3D effect, dialog boxes were treated with a gray background.

The UI was designed as if it was affected by a global, directional light source, such that controls had shadowed and highlighted edges. Sections of windows and dialogs were beveled to make them look "inset" or "outset". Practically, the achievement of this effect required that the background on which the controls sat (the window or dialog box) have some color other than white. You can't have a highlight on top of a white background, since white is already the lightest possible color. They needed to turn down the contrast of the background so that the 3D effect would work.

Now, arguably, this is where the UX comes in. It was widely believed that making interfaces look 3D would make them more "user-friendly". Even at this early stage, when user-interface design was still in its infancy, you could see the emergence of the skeuomorphism principle—if we make objects on the screen look like their physical counterparts, then users will be more comfortable when interacting with them. For example, 3D buttons were more pliable—they look like buttons because they looked like they could actually be pressed (a concept known as "affordance", articulated most coherently by Donald Norman). And, wonder of wonders, when the user clicked on them, there was actually an animation effect that changed the color scheme to make the button appear to indent ("press") into the screen!
One can argue whether this 3D actually had the intended effect of making the interface easier to use and understand. Certainly it was widely accepted in the industry that it did, and nearly all computer operating systems followed suit. Everyone's controls looked slightly different—some option buttons were round, some were square, some were even diamond-shaped—but they all had the same 3D effect, which as a simple matter of practicality required an off-white background.
Certainly not everyone chose the same shade of gray. Some backgrounds were a lighter gray, others were a darker gray. But better yet, the user wasn't actually stuck with gray at all. Window managers provided a customization hook where advanced users (or those with visual disabilities) could reconfigure the appearance of their system, choosing different colors. Light and dark variations on the background were used to create the 3D effect.

So arguably dialogs never really did have gray backgrounds—they just had non-white backgrounds. The reason people think of dialogs as having gray backgrounds is that the default themes shipped with the operating system usually used a light gray as the base color. Again, the designers did that for relatively practical reasons: gray is a color that virtually everyone can agree upon. Even if no one likes gray, no one hates it—something that you can't guarantee if you shipped out a window manager with rose-pink or teal-blue dialog boxes.
Now that the field of user-interface design has evolved, this is something that occasionally gets designers into trouble. They go through a lot of work creating an interface that they think is absolutely beautiful, with effective use of color. Then they release it on their unsuspecting users…who, it turns out, absolutely hate blue. They probably wouldn't hate it so much if they didn't have to stare at it all day, but your program forces them to do just that. All because some designer somewhere (or a team of designers) had the subjective opinion that a particular shade of blue really made the UI pop.
Although this will be controversial, I feel very strongly that fundamental color choices like this are not something that should be up to designers of individual applications. The user absolutely needs to possess the ability to customize the color scheme if she desires (personal preference) or needs to (accessibility reasons), and it is just far too unwieldy for each program to offer a unique interface for customizing its own appearance. A much better idea is for everyone to piggyback off of the operating system's built-in facility for doing this. And as an additional bonus, you get consistency. This is anathema to some designers, who absolutely cannot abide the idea of relinquishing control of every detail, but consistency is much more important to users. If your application looks and works like the other applications they use and have taken the time to learn, then it will take them substantially less time to get up-to-speed with using your application—even if there are some aspects of the design that you could argue are "sub-optimal." Consistency trumps innovation unless you have a darn good reason. Liking the color blue does not qualify.
Anyway, returning to our story: as fashions change and evolve, the old becomes new again. Windows Vista introduced the Aero theme, which lightened the shade of gray used by windows and dialog boxes—as you can see in the first screenshot in the question. Windows 8 took us full-circle, flattening (or nearly so) all of the controls and returning to stark-white dialogs that harken back to the days of Windows 3.1:

Worse, the (limited) customization ability that has long been a hallmark of a well-designed window manager is fading away. The user had been taken out of control—this time not by independent app vendors, but by the developer of the window manager. Someone who should know better. Why did Windows go back to a "flat" theme? Because everyone was doing it on the web, and a team of designers thought it looked "fresh" and "modern". Web applications, for their part, had started out doing this primarily because of technical limitations: because they ran in a browser rather than a full-fledged window on the desktop, they didn't have access to the window manager and they were left to implement their own windows and dialogs:

Obviously, these are inspired by the window manager's dialogs, but they are not the same. You can't be consistent with the operating system if you run on all operating systems. Where do you put the close button? On a Mac, everyone knows it goes on the top left. In Windows, it has been at the top right since Windows 95. On the web, it is anyone's guess where it might be. Same deal for the ordering and alignment of buttons. The consistency that was just beginning to make computers seem user-friendly began to evaporate because of these silly technical limitations, and then as web apps became increasingly popular, their design began to catch on as well, so that they looked more "modern" and "fresh" than did the "old" desktop applications. Time to fire up the old copy machines again!
Unfortunately, we still do not have consistency. Some dialogs in Windows 10 have stark white backgrounds, while others still use light gray. There is no obvious reason why. And the user cannot customize it.
There are undoubtedly usability arguments to be made on this topic. There is plenty of empirical research that suggests contrast is critical, but too much contrast can lead to fatigue. Black-on-white and white-on-black are both relatively poor choices. But there is no evidence that anyone has considered these arguments when designing dialog boxes.