Okay, here's my theory (I'm still searching for where this happens, but I think this is it):
The Demo starts with asking the player to select a perspective. However, it REQUIRES that you do this with a mouse. Pausing and unpausing here doesn't do anything, and if the game is paused and unpaused with the perspective selection screen active, the controller is never properly recognized (meaning the Triggers don't work, and, tellingly, the help text says, "Press F1 for controls" rather than "Press back for controls".)
So this screen is enforcing that the keyboard+mouse, and ONLY the keyboard+mouse, are controlling the input. Once you're past this screen, if you don't pause, it never moves out of the keyboard+mouse mode.
If you pause, THEN the game does the check to see if a controller is connected, and switches to that model. Note that it never UNDOES the keyboard+mouse; both will work after pausing.
The reason for this, I'll bet, is that the triggers are AXIS controlled when a gamepad is connected, and BUTTON controlled when just a mouse is used. Since the game is asserting that you'll start off using the keyboard+mouse (because you have to for the perspective selection screen, because the mouse POINTER has to be active), it never bothers with the additional check for Fire1 and Fire2 as Input.GetAxis (or GetAxisRaw, I s'pose).
Since you can, in both modes, change perspective from third- to first-person on the fly (which is one of the highlights of this package), what we really need is a demo that just skips that perspective selection screen, drops you in as first-person, and then advises you on how to switch perspectives in-game. That way the game can run the "is there a controller attached" check on startup, rather than waiting until after the perspective is selected AND the editor (or game) are paused and then un-paused.
I don't have time tonight to plow through unwrapping everything that DemoManager sets up just to remove this screen, but I'll bet the problem is in there somewhere.