There's an ambiguity in the term S-box as to whether it means a general look-up table or specifically a bijective substitution function. I've seen both uses.
If we mean a general look-up table, then there are examples of ciphers that use 32-bit words as entries. A good example is MARS which uses a 512-long table of 32-bit values. MARS was one of the AES finalists and so has had cryptanalytic attention but no significant security weaknesses have been found that I know of. If I recall correctly though, MARS was not as efficient as AES.
If we mean a bijective substitution function, as @fgrieu comments, memory constraints mean that large look up tables are not feasible. However, in the recent Chinese Association for Cryptographic Research block cipher competition, one of the entries SPRING implemented a bijective 32-bit function in hardware as a component of the block cipher and this component was described as an S-box despite not being implemented as a look up table. I don't know how much analysis has been done of SPRING, but I'm not aware of any sub exhaustive attacks. In terms of performance, the SPRING authors' claim that their design is particularly suited to hardware implementation and give competitive timing data.
An argument against large S-boxes is that they are harder to analyse than the typical 4-bit and 8-bit S-boxes. Cryptographers require that S-boxes have strong non-linear properties to resist linear and difference cryptanalysis and these properties can be exhaustively tested for a given 4-bit or 8-bit S-box (indeed Saarinen has essentially exhausted all possible 4-bit S-boxes to find the ones with the best properties). Such exhaustive testing is very expensive for large S-boxes and the computation to find a good, large S-box can be prohibitive.
