Why is it there?
It's basically because of Object Oriented Programming. In OOP, for matter of coding efficiency, you tend to create sub-classes of classes to re-use some or all of their properties. Since Image Textures and the Render Result slot derive from the same parent class, they inherit all those properties. The fake user property is already part of the parent, so there is actually no way for the child class NOT to have it.
Keep in mind that you're not setting a fake user on the render result itself, but on the datablock displaying it. Think of it as a container. This container inherits from ID, which holds the
How could it make sense?
Well, there is a case where you can make use of it. The Render Result slot isn't just the pixels, it's a whole datablock with properties attatched. One of those properties is a Render Slot name per slot. If you set the fake user, names you give to render slots will be preserved upon file save. In the example below, I created a render slot named
Demo. When saving and reloading, the named slot is kept. If you don't set a fake user, you lose that data.
As I am aware of, there is no benefit in marking a render result as fake user, as rendered image will disappear after closing a project. You can't use it as a texture for example (if it's not saved).
Since render result is treated as image, and all images can be used as fake user, you can click on fake user to mark is as such, but...developers probably didn't make it as exception, either deliberately or either not. You can fill bug if you thing this should be solved.
I GUESS (!) you can add a Fake User to the Render Result because Blender itself treats the render output like a temporary texture (that will be gone after closing, yes); and because it is treatened like a texture, you can add a Fake User to it.
For any "real" texture, the Fake User prevents the texture to get lost if you don´t use the texture in any way (material/node/UV layout etc.) but still want it in the file.