I've done a great deal of work with both networks and they both have their place.
DeviceNet is best for very small packets (a single frame can only handle 8 bytes of payload), small microcontrollers (CAN is very popular in automotive applications), and small devices. Motor overload relays, small I/O blocks, photoeyes, valve manifolds; all of these are good applications for DeviceNet.
EtherNet/IP needs a more powerful microcontroller or microprocessor and a much more sophisticated network stack. The speed of an EtherNet/IP connection is almost always limited by the device's computing power, not the wire speed or the switch speed. A single I/O connection can carry 510 bytes without fragmenting. It's excellent for devices that need to do both I/O and messaging, and you can easily mix other application protocols on the same wire. Having devices that support common computer protocols like HTTP, FTP, e-mail, BOOTP/DHCP, etc is a huge benefit.
The convenience of built-in PC connectivity and inexpensive media are terrific for EtherNet/IP. The PC connection isn't that big a deal for DeviceNet; most applications "pass through" the PLC or use a USB/DeviceNet interface (yes, expensive).
In my opinion a properly installed network with either technology is very physically robust. I used to deal with a lot of DeviceNet troubleshooting where users complained that the network was "flaky" or "finicky" but I always found simple or obvious violations of simple wiring rules: no shield, or loose connections (once, a junction box full of wire-nuts and water), or missing termination resistors. Now that EtherNet/IP has a lot of installed base I find just as many damaged Cat5e cables, bad crimps, broken RJ45 tabs and faulty switches.