Oddly enough I've always found command-line SVN lacking. Visual indicators seem to take version control to a much greater level.
Eg, if I see an odd emblem on something I don't remember modifying recently, I can inspect and diff. It could be some minor string fixes, or something more substantial. Either way, rather than doing a whole-tree commit (which wouldn't include a comment for the file I didn't remember editing), I'll now do a granular commit to that single file with an appropriate message.
My experience has shown the opposite -- the worst programmers to work with on a project are the ones using Tortoise*. I've noticed more missed files in commits and poor branch management with Tortoise users than with command-line users. Of course, this is mere correlation rather than causality.
I've never found much of a need for a GUI for version control -- especially with SVN, which has such a simple model (visualizing the revision graph for something like Monotone is useful, because it can become complex). Viewing diffs is trivial from the command-line, for example, and faster than using a GUI.
For me diffs are more viewable with decent visualization. '14c57' doesn't compare so much with a visual expansion marker connecting the previous and current states.
NaughtySVN appears to be at version 0.0.1, so I wouldn't rely on its stability yet. When I wanted a SVN GUI on Linux a year ago I ended up using RapidSVN, and that seemed fine. I usually do filesystem navigation on the command line or inside vim when I'm programming, so I don't mind launching a separate GUI program for nontrivial version control.
NautilusSVN has three developers, has been going a year, and is undergoing it's first major rewrite for 0.12, a few weeks away - hence the upcoming in the title.
I'm intending to jump in (as a user, and perhaps a developer - it's Python / Glade/ GTK) when 0.12 is out.
I could've sworn I saw this project, or another by the same name and with the same intent, in an Ubuntu repository a year or so ago. If that's not a hallucination, then it looks like maybe the project was imported into Google Code last June 20. In which case, it's good to see the project has come back to life.
Eg, if I see an odd emblem on something I don't remember modifying recently, I can inspect and diff. It could be some minor string fixes, or something more substantial. Either way, rather than doing a whole-tree commit (which wouldn't include a comment for the file I didn't remember editing), I'll now do a granular commit to that single file with an appropriate message.