Why restricting SHA3 to have only two possible capacities?
2 main reasons: 


The 2 capacities match the collision resistance of SHA2 for 32-bit (C=256) and 64-bit (C=512) word sizes.
Simplicity, having only 2 capacity/rate combinations means that it does not have to be chosen or calculated from the digest size.


I have implemented Keccak in software, and forcing only 2 capacities means a lot less code in the absorb/squeeze functions. The idea of only 2 capacities with those values was suggested by the designers of Keccak themselves in section 6.2 of their Sakura tree hashing proposal:

Sakura: a flexible coding for tree hashing


Keccak's SHA3 submission originally specified C=512 for a 256-bit hash and C=1024 for a 512-bit hash. The reduction in the slides means 2 things:


Speed; it is 23% faster for 256-bit hashes and a whopping 89% faster for 512-bit hashes due to the corresponding rate changes
Security; resistance against preimage and collision drops from $2^n$ to $2^{n/2}$, where n is the digest size in bits, this would make SHA3 weaker than SHA2, which has preimage resistance of $2^n$


Keep in mind that SHA3 has not even reached draft stage yet, and there are plenty of people who disagree with the chosen capacities, so it may very well change prior to FIPS 202.