Let's be clear what this thread is about. This is about game streaming in the sense of OnLive or Google Stadia. It has nothing to do with the physical thickness of any device involved. There have been a number of threads about this over the years, and I've replied to a lot of comments, but hadn't created a thread to lay out the whole situation systematically until now.
The idea of a thin client is that you don't have the heavy processing power in the device that you're directly using. Rather, you have to log in to some remote server that does the heavy lifting, and just sends you the result to display on your screen. In a sense, thin clients are the descendants of dumb terminals for shared mainframes from an era when it wasn't practical to give everyone his own computer.
As applied to gaming, the real question is where rendering the game is done. If your local machine does most of the computational work to generate an image and display it to you, that's a thick client, not a thin client. If the game is rendered elsewhere and sent to you, and all your device has to do is decompress it and display it, that's a thin client. Your cell phone is not a thin client, for example. A device that is plenty capable of rendering a game on its own can be used as a thin client. If a device is only going to be used as a thin client, it's also possible to use a small, cheap device that isn't capable of doing much else.
I don't use the terminology "game streaming" here as that is also used in the sense of Twitch, which is totally different. Besides, for those who have had the misfortune of having to use a thin client in a corporate context, the epithet of comparing something to a thin client absolutely applies here.
The way that games are normally rendered is that the video card does various computations to generate frames, then it sends those frames to a monitor to display. There is a wired connection from the video card to the monitor, and it is dedicated to be used just for moving the rendered frames from former to the latter. It's also a fairly high bandwidth connection, as it takes several Gb/sec to transfer 1920x1080 images at 60 Hz, for example. That's how it works in everything from a gaming desktop to a laptop to a cell phone, though smaller devices tend to have an integrated GPU rather than a discrete card.
With the thin client approach, the game is rendered on a remote server. It has to transmit the images to you before your device can display them on the screen. Unlike local rendering, there generally isn't a dedicated connection. There also tends to be massively less bandwidth available. That means that transmitting the full, uncompressed images tends to be impractical. You could send uncompressed images over a LAN with 10 Gbps Ethernet, but that is sadly still uncommon for consumer use. And while it is possible to have a game running on your gaming desktop and stream it to your phone, the use case that gets a lot more attention is having the game running on a remote server that you connect to over the public Internet.
This has a variety of advantages and disadvantages. The biggest disadvantage will be thoroughly familiar to anyone who has spent a lot of time using a thin client for non-gaming uses: it doesn't work very well. It's not that it doesn't work at all. It's just really clunky in day to day use, and prone to the hiccups for a variety of reasons that are impossible when rendering the game locally.
One if the problems is bandwidth. Even if you have a 1 Gbps fiber to the home connection, your ISP isn't likely to let you actually use 1 Gbps for a few hours per day in an average day. Even if they did, that's not enough to transmit uncompressed data. Rather, it's going to take an awful lot of compression.
One approach to this is to compress each image on the remote server and send it, then decompress it locally. If you do this with each frame in isolation, it's not going to work very well. Good compression and decompression is a lot of processing load, and to get the size down to something manageable is going to take very lossy compression that looks terrible. So that's not what they actually do.
If you watch a video, such as on YouTube or Netflix, they compress across time. Consecutive frames tend to be very similar to each other. If you have the entire video in advance, you can look at what doesn't change from one frame to the next and make compressing a hundred consecutive frames that are all nearly identical not take that much more space than just one frame.
That's not possible for gaming, however. They can't look at what they need to send you far in advance and compress it. They have to send what they have now, even though they don't know what's going to come soon. You can get better image quality with more bandwidth, but without the ability to have the entire video in advance to readily compress across time, the image quality at a given level of bandwidth is going to be far inferior to what you may expect from watching Internet videos.
That doesn't mean that they can't compress across time at all, however. They can do a delta compression of sorts where they they tell you what changed in one frame from the previous. This can look pretty good so long as not much changes from one frame to the next. This would be fine for a lot of simple things, such as visual novels where the rendering is simple enough not to meaningfully tax your phone.
The problem is that this falls apart when the image changes radically and abruptly. Moving from a loading screen to displaying a game will do that, for example, as you move to an image completely independent of the previous. But that will just look bad momentarily before it's able to catch up over the course of many frames. And making loading screens effectively last an extra fraction of a second isn't a big deal. Far more problematic is that rotating the camera rapidly will cause the same sort of problem. That's likely to be done when you need to see what is off in some other direction immediately.
Another problem is latency. Compressing an image, transmitting it, and decompressing it intrinsically takes more time than not doing that. Additionally, sending input to the remote server also takes time. This adds delay to make controls feel sluggish, as it takes some extra tens of milliseconds between when you tell the game to do something and it registers.
Some online games already impose something like this latency, by making it so that when you tell your character to do something, it doesn't actually do it until the server finds out about it and verifies that it's legal. That's less latency without having the added compression and decompression steps. But it's enough to be annoying--so much so that games commonly have your character immediately do whatever you said, then only override it (by rubber-banding) if the server later tells you that it was invalid.