This doesn't seem to be caused by Snaps or the Ubuntu MATE Welcome application in particular. It seems to be caused by a buggy version of one of the Ubuntu MATE Welcome application's dependencies -- WebKit-GTK. Specifically, it appears to be related to this:
To summarize, the bad news is that it looks like it's not going to get fixed in 23.04; it's too late in 23.04's lifetime to release a fix. The good news is that 23.10 has a patched version of WebKit-GTK, and 23.10 is due to be released in a week or two at most. So if you are willing to upgrade to 23.10 when it comes out, then you'll be good to go.
That's the simple answer. Below, I will explain in painful detail what exactly is happening. You don't need to read what I have to say below, but for the curious, here goes:
Believe it or not, the Ubuntu MATE Welcome application is not a conventional desktop program as we know them to be. It is mostly a large set of fancy Web pages, with a little bit of real program code to perform actions such as install extra software and change your desktop theme.
To display those Web pages, the Welcome application uses a program component called WebKit-GTK. WebKit-GTK is a port to Linux of WebKit, which is the component used for displaying Web pages in Apple's Safari Web browser on Mac OS (macOS? I can never remember what it's called this week 
). The Welcome application relies on WebKit-GTK so much that basically the entire Welcome window is drawn by WebKit-GTK; hence, when something goes wrong with WebKit-GTK, the entire Welcome window remains blank (as is shown in your screenshot).
WebKit, like the "Web engines" of most other Web browsers, uses the advanced capabilities of your GPU if available. After all, the animations and other graphical effects on modern Web pages are not easy to draw, and use a lot of CPU power too! But for some reason, the Welcome application force-disables the use of your GPU to help with the rendering of the Web pages, instead forcing all drawing to be done by your CPU -- an inefficient process. At least, GPU rendering has been disabled since the Welcome application was converted to a Snap; I saw this line of code while perusing the Welcome application's code (https://github.com/ubuntu-mate/ubuntu-mate-welcome-legacy/blob/master/snap/snapcraft.yaml#L80) a few minutes ago:
LIBGL_ALWAYS_SOFTWARE: 1
I have two working hypotheses for why the Welcome application would disable GPU rendering and always use software / CPU rendering:
- Graphics drivers on Linux are notorious for being buggy. Ask any owner of a video card from Nvidia, or even many owners of AMD video cards. Buggy video drivers can cause all kinds of glitches in the display of content onscreen, from occasional flickering to application windows that are painted entirely black, to even freezing the entire computer in some extreme cases. The Welcome application was intended primarily for new users of Linux. If a new user boots up Ubuntu MATE and sees a messed-up display when the Welcome application launches, how promising is Ubuntu MATE at large going to seem to them? It won't seem promising, so for safety's sake, to ensure that every user can use the Welcome application (even if it drains their CPU power in doing so), GPU rendering is disabled.
- An even more plausible hypothesis is that it may not even be possible under some circumstances to use GPU rendering, especially inside of a Snap. If I recall correctly, Snaps are (by default) constrained from reading any files other than a select few which have been specifically whitelisted for use; this is allegedly for security reasons. Nvidia GPUs in particular often use proprietary drivers, unlike most other GPUs which have very good open-source drivers available. If my memory serves me right, in order for a Snap to use GPU acceleration with an Nvidia GPU, a copy of the Nvidia drivers has to be included with the Snap itself. Not only would that (legally speaking) turn the Snap into a proprietary product, but apparently different Nvidia GPUs work best with different versions of the Nvidia drivers; a modern card might work best with version 490 of the driver, whereas a two-year-old card might work best with version 432, for instance. Each driver version is huge, consuming even a hundred or more megabytes of disk space; packaging a dozen versions of the Nvidia drivers in a Snap might consume a gigabyte or more. That's absurd, especially if the only reason for doing so is to have GPU rendering for your rinky-dinky Welcome application!
Whatever the rationale for disabling GPU rendering in the Snap version of the Welcome application, this apparently led to trouble, and revealed a bug in WebKit-GTK that had remained unknown until recently. In computer graphics, at least modern computer graphics, RAM memory is essential and fundamental. Open a new window on your desktop, and video memory is reserved and set aside for the contents of that window. Your application draws into that video memory, and then the GPU's job is to resolve which parts of the window's video memory actually need to be drawn on-screen; the GPU's job is known as compositing, as the GPU takes all the windows on-screen and produces a composite image that is seen on your monitor screen.
In addition to the video memory allocated for a window, an application (or something like WebKit-GTK which is a dependency of an application) may request additional regions of video memory. In the most common scenario, one or more of these extra memory regions are used for a technique known as double-buffering. Basically, double-buffering is where the application draws into a video memory region which is intentionally not displayed on-screen. Then, when it's done drawing, the application asks the GPU to "swap buffers" -- the GPU will use the off-screen memory region to re-draw the window, while the memory region that was previously on-screen and used to draw the window is moved off-screen. The latter region, now that it's off-screen, is then made available for the application to draw into, and when the application is again done drawing, the buffers are swapped again.
If the above description of double-buffering sounds a bit convoluted and unnecessarily complicated, let me assure you that there is a reason for its existence. Computer monitors update their displayed content at a fixed interval, often 60 times a second, or approximately every 17 milliseconds. If double-buffering were not used, it is possible -- in fact, it is likely in the long run -- that at some point, while the program were still drawing, the monitor would need to refresh again, and the monitor would display the partially-completed image in the application window. If the program were not careful about the order in which it drew the graphics in the window (applications rarely are careful about that -- it's just too hard and time-consuming), the result is a broken-looking image being displayed on-screen for a very brief period of time, which to our human eyes looks like flicker. Nobody likes flickery images. By contrast, by drawing everything into an off-screen buffer first, then displaying the completed image all at once once it's ready, there never is a chance for the monitor to display any partial images; the user never sees any flicker, animations are smoother, and the user is happy that their high-end graphics card doesn't produce amateurish, flickery graphics.
Now, there's a problem with how WebKit-GTK did double-buffering, at least until recently. WebKit-GTK requested video memory for the off-screen buffer using that DRM_IOCTL_MODE_CREATE_DUMB command that you see mentioned in the terminal window in your screenshot; WebKit-GTK was asking the GPU for some of the GPU's video memory for that off-screen buffer. But since WebKit-GTK is using software / CPU-based rendering and is not using the GPU, it doesn't make sense to allocate video memory from the GPU -- software rendering never uses the GPU. The Permission denied message is a little misleading here, as it would indicate that you need extra permissions to access the GPU, but the fact is the GPU shouldn't be accessed at all when software rendering is enabled. So, WebKit-GTK recently was fixed so that the off-screen buffer is allocated the same way that the on-screen buffer was allocated, to avoid this exact issue.
But it appears that WebKit-GTK 2.42 is the first version to include this fix, whereas Ubuntu MATE 23.04 shipped with WebKit-GTK version 2.40 (which is a buggy version). Usually, only security-critical programs and libraries are updated after a version of Ubuntu is released, and 23.04 is already two-thirds of the way through its support cycle, so even if you reported this bug, the chances that it would get fixed before this release reaches End-of-Life are slim. But again, 23.10 is going to come out soon, and it features WebKit-GTK 2.42 (which is supposedly patched against this bug), so that's some good news, right?
If you read my diatribe above, thanks for reading. I'll at least feel that I didn't waste my time 
.