In regards to you specifying a software rasterizer, nothing serious in use today uses software rasterizers.
The fact that you need to limit the discussion to an objective word like "serious"... isn't that a bit one-sided?
For example I have handled a few servers in my time, and outside a Linux distro built on an Ubuntu base or something, the majority of servers tend to have nothing but a framebuffer driver installed.
Consider Minecraft. It's a multiplayer game, with dedicated server software. This software can be run on home computers and dedicated servers just as easily, and is cross-platform. So this server software often needs to run in an environment with no graphical hardware acceleration, including a total lack of OpenGl support.
Now, unlike most games, light levels play a critical role in the game. They determine where and when monsters can spawn, and affect plant growth for food. However in a multiplayer environment, the server needs to be able to do and pass block light calculations to the players.
So all the original lighting calculations need to be done on the CPU, without any GPU assistance. Once those original calculations are done the clients can just take that info and use their GPUs to display it in varying levels of niceness.
This screenshot was taken in an older version of Minecraft, multiplayer. Nobody else was in the area I was in, so the are wasn't loaded by the server. I went over there, so the server started loading up those chunks of land and doing the light calculations. And it fucked up, as you can see. The right line of torches does not give out light as far as the left line.
This is not just graphical, however. The server messed up the lighting calculations, and until my client causes a recalculation (affecting the lighting near that area somehow), monsters will be able to spawn in it, if there were crops there they wouldn't grow there at night, etc.
And to get back to the main point, stripping versus disabling...
minecraft.jar for 1.5.1 is 5.3MB.
minecraft_server.jar for 1.5.1 is 2.3MB.
A few megabytes is not much and asset removal is likely a good bit of it (don't need the textures on the server implementation, etc.), but it is over 50% savings on disk space for just the binary.
And hey, what about GBC/GBA games? Stereo was only available via headphones for a long time, so most games went with mono sound, because stereo was more expensive (speaking in terms of resources, not specifically cost).
Even then, Unreal could be ported to use a software rasterizer--it just wouldn't be in any way playable.
...
unless they removed certain features.
For example, I played Quake II with the software rasterizer (yes, games back then had that natively) on my Windows 98 machine because my SiS 530 didn't support the right stuff for hardware acceleration. And it ran playably on my AMD K6-2 clocked at 475MHz.
Now, granted, I was presented with this...
Opposed to this...
Because features like dynamic lighting and texture smoothing were not supported on my hardware. Also note the lack of the decal on the window to the right, water transparency was missing, etc.
But the game ran, it ran playably, and I beat it multiple times like that. This is an example where stripping features out of the just renderer makes it run playably on simpler hardware, while keeping the option for the features in the game itself, so people with better hardware could use them.
So I don't see the point... Unreal is a very scalable engine, and features don't have to be "removed" to increase performance. Rather, they can just be unused. That's the great thing about modern rendering pipelines.
Okay, I think this is the source of the confusion. Here's what I'm talking about.
Removed: Not done by default
in the distributed binary, and no options added to enable it. Akin to minecraft_server.jar not doing rendering and presenting a totally different UI.
Disabled: Optionally removed for compatibility with older/weaker systems. Akin to having multiple rendering options.
And I think what you're talking about is removing the ability to add heavier features from the SDK/development environment in total.