I have used SproutCore in the past. I was assigned a project to develop automated web testing scripts using the tool called Selenium RC. Selenium RC was built to target regular HTML id's and classes, but SproutCore compiles the element IDs so that the element IDs are pseudo random, so I had to figure out the API for SproutCore so I could fish out the element IDs from the view tree.
SproutCore has a close analogy to compilers. If you have too many elements that you're importing creating for your web page, there's a chance you'll have a namespace collision on the IDs if you were to build your application with jQuery. When you're building your web page with jQuery, all the IDs of HTML elements are globals. There's no such thing as local scope as in a compiled or interpreted language.
SproutCore ends up managing the HTML content for you. The views are built up using javascript and then compiled. If you go through the SproutCore tutorial (and I agree SproutCore is lacking in documentation so you should try to avoid it for a business application), you'll see that your finished project has ID elements of "sc-###". Namespace collisions become resolved on the website giving you the potential to work faster.
However, there's major concerns. They documentation doesn't do a good enough job explaining why people should use it. The project is opensource, but digging your way down to understand the lower level javascript for how the views are built become painful. Javascript is a functional language, but I just find something wrong with dynamic functional languages. There's just too much flexibility. I'm plugging Scala.
The last issue. SproutCore can be slow. But it's a price to pay