If you setup an "Article" content-type, and a "Review" content-type with Fivestar CCK fields targeting an Article node (ie, via a NodeReference CCK field), the fivestar ratings and targets are recorded properly in the content_type_review table, but nothing shows up in the votingapi_* tables.
For the ratings to register with VotingAPI properly, you MUST also enable "Fivestar ratings" on the *target* node's content-type (ie, the "Article" content-type in this example). A cursory inspection of fivestar.module leads me to believe this is by design; _fivestar_cast_vote() always calls _fivestar_validate_target() to test the target.
Regardless of whether this requirement is by design or not, it is not covered in Fivestar's documentation on how to use CCK fields. The documentation only specifies that the review's Node ID (ie, the "Voting target") must be populated for the vote to register with VotingAPI. (Ie, "no vote is registered in VotingAPI without the Node ID field filled out")
Additionally, the documentation gives the distinct impression that the "Simple Rating" configuration (in the content-type settings for the target node) and the CCK configuration (in the field settings for the "review" node) are wholly independent of each other; it reads: "Fivestar has two COMPLETELY SEPARATE modes of operation. The first is letting an end-user rate a piece of content. The settings for this are on the content type settings page."
And finally, in the step-by-step instructions for "Configuration as a CCK field / Advanced Rating", nowhere does it mention that you need to enable anything on the target node, it only discusses the review node, and mentions that CCK ratings "COULD be combined with a standard rating on the target node".
Well in my testing, this is inaccurate phrasing; CCK ratings *MUST* be combined with the "standard rating", at least insofar as the latter being enabled, even if it is unused or hidden from the end user.
I think this point is causing confusion for developers trying to use Fivestar in "pure CCK mode". I've seen a few comments scattered around that seem to indicate others have discovered this "hidden requirement" as well, eg:
http://drupal.org/node/243012 - Comment #25: "I realized that if the target node type does not have voting enabled, the vote will be disregarded entirely. [...] it would be ***extremely*** useful if a comment could be added to the 'target node id' config area that makes it crystal clear that the target node type must have fivestar enabled."
http://drupal.org/node/248503 - Comment #5: "if I enable fivestar on the parent node itself as well as for the cck field, I can vote on the node from the front end, then edit the original review (parent node) and the cck field fivestar rating will then register."
So to sum up... if "Review" nodes built using Fivestar CCK should NOT need the target node to have "Fivestar enabled" for ratings to register properly with VotingAPI, then this is a bug and should be fixed. If, however, this IS by design, then the documentation (and/or help text in the admin interfaces) needs improvement to clarify this very important point.
Currently, to get Fivestar working in "pure CCK mode", you should enable "Fivestar ratings" for the TARGET content-type, but set the Teaser and Full node displays to "Hidden" to hide the unwanted simple rating widget from end users. I also believe this is a much simpler answer to the "$50 Documentation Bounty" question (http://drupal.org/node/208054) than using some workaround with NodeComments as presented.