The 26w & 8w i/o header (and CSI/DSI flat-flex sockets) are taken direct off the SOC pins with no external 'protection' what-so-ever (internally there are a pair of diodes - one to Gnd, the other to 3.3v). The B+ adds some extra i/o pins - the 26w & 8w header are replaced by a 40w header - however the pins are still connected directly to the SOC. Again, the lack of hardware design experience shows - whilst pins are common on PC motherboards (which are typically protected inside closed metal cases), all 'prototyping systems' have SOCKETS, not PINS. The 26w has 6 'general purpose' GPIO pins, plus another 11 with 'standard' functions (although all can be reprogrammed). Poor layout makes it difficult to 'pick off' one or two i/o pins together with Power and Gnd using a short header strip connector - the only exception being the serial RxD and TxD (Pin8 and Pin10) which can be 'picked up' with 5v (Pin4) and Gnd (Pin6) using a 4way header. All other Power and Gnd pins are separated by at least 3 other pins, so you need at least a 5 way connector, which is a REAL PAIN since 4way 0.1" cable connectors are 'common' (they are used for fans and USB connections to PC motherboards) whilst 5 ways is not (as anyone with some hardware design experience would know) Then we have the GPIO pin 'ID number'. First there is the header Pin number. Next there is the 'GPIO (or BMC) pin number' and then 'software setup (gpio-) number'. The initial usage of 'GPIO' and 'gpio' caused such confusion that most people now use 'BMC' rather than 'GPIO' = however all the older 'how to' guides still use 'GPIO' and even today many writers interchange the 3(or 4) different ID numbers leading to predictable confusion (the Pi forums are full of questions like "Why won't my application work with my circuit on pin X ?"). ... and just when you think it's safe to 'pick a pin', along comes Ruby and Python with the "WiringPi" pin-outs, which introduces yet another level of confusion - so, if you want to access the serial TxD, is it on pin 8, 14 or 15 ??
Whilst the CSI/DSI flat-flex connector pins are enclosed, the GPIO header pins are totally exposed = 0.1" bare pins stick up in a row at one end of the PCB - and since just 'brushing against' the header pins without taking static precautions could be enough to 'blow' the SOC (or at least the protection diodes), this is a 'total disaster waiting to happen', especially in the 'educational' field.
Of course, blowing a few Pi boards will teach (some) kids about the dangers of static etc. however this could soon get very expensive for the 'average' school :-)
One solution is to plug in an external PCB (such as the 'Gertboard') which incorporates circuitry to protect the SOC pins along with space to add your own components - or go straight to a 'plug on' board such as the 'Pi-Face Digital' (which includes a couple of relays) - however both these cost about the same as the Pi
NB. With the Gertboard you have to provide your own ribbon cable - and here you may be able to 'make do' with an old 34w floppy disk cable (if you can find a short one) - whilst the PiFace plugs straight onto the Pi's header pins.
No doubt Chinese equivalents to the 'Gertboard' etc. will soon be available on eBay at a more affordable price
Finding the 'hardware specification' of the GPIO pins can be difficult, however Google turned up this
In output mode, the pins can drive Lo (0.4-0.66v) or Hi (2.6v - 2.9v) but only at a very low current (2mA typ., 16mA max for any one pin, 50mA max for all pins combined), so if you try to 'direct drive' anything other than low power LED's you will blow the i/o pin (or the SOC chip). Direct driving of capacitive loads is a total 'no-no' (if you must, drive via a 200 ohm resistor - which, of course, imposes a limit on the maximum output frequency achievable). In input mode, you can make use of the internal, optional (software controlled), 'pull-up' or 'pull down' circuit. Of course omitting any external 'protection' for the I/O pins preserves flexibility (since you can define the GPIO pins as 'inputs' or 'outputs' with or without pulls-ups or pull-downs, and any sort of 'interface' circuit would restrict this) but it makes the SOC very 'vulnerable' to GPIO pin 'miss-use'
A minimalist solution when needing to use a GPIO pin as a push switch 'input' is to wire the pin direct to Gnd via a 10k resistor and have the switch 'pull up' the pin via a 1k to 3.3v. Whilst this avoids RFI pick-up on the switch wires being injected into the 3v3 line this is not recommended for switches at the end of long cables.
If your switch is on the end of a long cable, you do need to worry about RFI pick-up on the wires being injected into the SOC chip - and blowing your Pi !
The solution is to use an 'opto-isolator' on all inputs (which also addresses any 'voltage level conversion' you might need - for example on serial TxD from a PC).
It's to be noted that many of the pins have 'standard' functions. For example, GPIO 14 & 15 (on header pins 8 and 10) are the 'on board' serial link UART TxD and RxD respectively and, at power-on, these 2 pins are programmed as a 'debug terminal' (you will find status reports are sent out on TxD during power-on). Whilst all the GPIO pins are under software control, there is plainly some danger in choosing a 'standard' output for use as an input that you intend to 'short to ground'. You should thus stick to the 6 'non-allocated' pins (GPIO 17,22,23,24,25 or 27).
I use GPIO 17, which is 'unused', but even so, to avoid a button push blowing the SOC (following a software error that sets BMC 17, on header pin 11) to output a logic 'Hi' by mistake, I always fit a 1k ohm resistor between header pin 11 and the opto-isolator pin 4 (to limit the current)