Here's the steam output of both systems while doing the following:

1. Steam starts
2. I launch EscapeGoat (streamed desktop to laptop, controller attached to client)
3. I notice controller is not working
4. I end the game on client side, game quits on host too
5. I stop capturing steam output

There is an additional FEZ stream attempt in host's output though that was both accidental and a failure (client system misbehaved and I had to restart to get it working), I've marked it so that you can skip it. You might also notice me changing capture target to desktop once, I was just checking the output capture, also commented.

I replaced some unnecessary frame strings with comments to reduce the length of the ouput, made sure to preserve the first/last few frames so as to avoid confusion. I've placed section comments between whatever steam did at the time to help navigate through the file.

So without further ado:
Steam Output (Host): here
Steam Output (Client): here

edit: Forgot there were streaming logs available, so much for teeing the output...

update: I recalled SeriousSam3 doesn't handle controllers in the same fashion most other games do (uses xinput, includes own configs and layouts, not even sure what's special about it).

I tried launching it and it does indeed work flawlessly, I should also point out there's no xpad/xboxdrv installed system-wide.

I'm going to try out controller in a some more games after they get downloaded, though I'm positive it's not game related, but steam/sytem related, especially since controller works fine in both systems while not streaming. Please don't Close this yet.

Almost fixed! Borrowing a ps3 controller which my steam user, SDL_Joytest-GL, jstest and wine could read, yet steam not so much, reminded me uinput isn't really the event device itself :)

I can get the controller working (while plugged into client) by adding the steam slave user to the input group, though that's something undesirable.

Whenever a stream starts steam creates a new eventX in host's /dev/input through uinput and removes it after the game stop executing in host (not when streaming ends), though apart from the controller event being the last one created and it not being there prior to the stream or afterwards there's no way to know for sure which event is the one created through uinput for the stream.

There doesn't seem to be any event id or anything of the kind to help nail it down in order for me to write a udev rule regarding it. How could I reliably find out which event/s is/are created by the stream so as move them to the games group for my steam slave user to access?

@Plagman can Close, I managed to nail the events down with this udev rule:

SUBSYSTEMS=="input", ATTRS{name}=="Microsoft X-Box 360 pad", GROUP="games"

For anyone coming across this thread searching for a solution, here's how and why it works:

After trying multiple games and controllers and reading the generated event info with: udevadm info -a -n /dev/input/eventX
I noticed the parent device's ATTS{name} is always "Microsoft X-Box 360 pad" no matter the game streamed (and its controller layout configuration) and the actual controller used (tested with a logitech rumblepad2 and a dualshock3).

Where eventX is the current event generated by uinput. The easiest way to find out which events where generated would be to simply use ls -al /dev/input/ once prior to launching the stream and again just after the stream starts. The extra events should be the ones generated by uinput (generally speaking the number appended after "event" should be the next free one after the event with the biggest integer)

In my case it was event9 so I tried udevadm info -a -n /dev/input/event9 (while stream was running).

The output should be of the following form:

#looking at device '/devices/virtual/input/input96/event9':
KERNEL=="event9"
SUBSYSTEM=="input"
DRIVER==""

#looking at parent device '/devices/virtual/input/input96':
KERNELS=="input96"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{name}=="Microsoft X-Box 360 pad"
ATTRS{phys}==""
ATTRS{uniq}==""
ATTRS{properties}=="0"

The only reliable attribute seems to be ATTRS{name} since it's both the only thing to stand out and persistend between different streams utilizing different games and controllers.

Thus the following udev rule I already mentioned above:
SUBSYSTEMS=="input", ATTRS{name}=="Microsoft X-Box 360 pad", GROUP="games"

That rule should change the events' group to games as long as they are generated whenever you start streaming. If your steam user is not in the games group you might want to add yourself to it or modify my rule and change games to a group like "wheel" or even replace GROUP="games" with MODE="0666" (which will allow every user to read from the event).

I'm very strict concerning my file permissions (even in such cases, yes) so I just won't do that and would rather stick to my games group instead.

You should also make sure to create a udev rule for uinput in case you haven't already:

KERNEL=="uinput", GROUP="wheel", MODE="0660"

or something similar, I won't restrict uinput to the game group since it's required for more than just steam and I want my regular non-steam-slave user to be able to access it.

Finally remember to reload the udev rules:

udevadm control --reload-rules

...and launch steam once again in your host machine in order to ascertain it's all working as expected :)