Heh. I was writing a driver a few years back (not mainlined) and completely ignored all the good advice I got about using a normal char dev to control my simple device. Instead I implemented a novel set of sysfs files for obtaining the state of the device. One file was written to chose the channel to read, and another file to read the measurement back. Nice and simple to manipulate from the shell for debug, but a complete disaster in real-world use cases. (ie. two processes cannot read from the device at the same time).
I completely abused sysfs in my driver. It was the wrong interface for actually interacting with the device, and I ended up rewriting the interface in the end. In this case the problems and issues were very much of my own making. :-)
Anytime I hear complaints about sysfs atomicity it raises a red flag for me and I wonder if it is a similar situation of using sysfs for IO instead of mere configuration. Using sysfs for IO is in a lot of cases broken.
I spoke to quickly in my earlier comment. Yes, you're right. sysfs has become the natural configuration interface for a lot of devices, and it suits that job very well. However, I still say that it doesn't replace sysctl for the non-device-centric configuration knobs (ie. the ip stack).