see http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094954.shtml
there are a lot of things involved with those timers, some of the things you seem to be concerned about look like premature optimization...
things you should do:
You want your core switch to be the spanning tree root. Set the bridge priority on your core switch to the lowest value. IOS lets you use the special priority 'primrary' which sets it to 8192, so I suppose you could use that. Make sure end user ports have portfast and bdpuguard or whatever Netgear supports for saying "this port should not feed other switches"
maximize hello time to minimize chatter (similar reasons to above)
I would not touch this, it affects everything else. I'm pretty sure increasing the hello time increases the time it takes to detect a loop, which is not what you want.
minimize forward delay to start sending actual packets as quickly as possible
This can be helpful if a cable is unplugged, but really it is only going to save you at most 30 seconds or so, which may not be enough to make it worthwhile.
increase path cost on standard ports to avoid connected machines from hijacking traffic
In ciscoland for end user ports you would enable portfast and bdpuguard and all that fun stuff.. end user ports should not be participating in spanning tree in the first place, so the port cost isn't really relevant.
decrease path cost on the link to the core switch to indicate preferable path
Should not need to do this if you make the core the spanning tree root
increase priority on the link to the core (same as above)
Should not need to do this if you make the core the spanning tree root
can these changes have impact on network performance (both lag and transfer speeds)?
No. The only thing they can help with is faster recovery if someone unplugs/reboots a switch. I'm going to assume that if that were to happen, any game in progress is going to get interrupted, so having it come back online after 15 seconds instead of 45 isn't going to make much of a difference to the players.
If you don't have a looped topology(aka redundant layer 2 links) then spanning tree isn't actually doing a whole lot.
Best Answer
In most deployments it is not necessary to configure STP on an access point. However, there are several deployment scenarios where it is advisable.
One such scenario I encountered in production when it was biting the network in the proverbial posterior.
Instead of running a physical cable to connect a printer on a shop floor, an access point radio was configured in what is called "workgroup bridge" role. In this case the radio interface plays the role of uplink to the LAN (associating to another access point that is actually plugged into the LAN) while the physical Ethernet interface connects to the printer. The printer worked great for a year until the business needs changed.
At some point additional printers were needed and a few physical cable runs and a switch (as part of an intermediate distribution frame) were installed at the shop floor location. The printers were plugged into the new switch -- which was plugged/uplinked into the LAN from the new runs. The access point physical Ethernet interface that was once plugged into a printer was also plugged into the new switch.
With both the access point physical Ethernet interface and the radio interface connected to the same broadcast domains -- a loop was formed. Storm-control was in place and caught the broadcast storm in both places. However, if it was not in place that would have been a very tricky loop indeed.