That wasn't what I was trying to say. Let me give you an example of what I mean (sorry for how long it is):
Imagine you make a Twenty Ten Child Theme that is just a style.css file with some custom CSS. While building a page, WordPress asks your theme for a file called index.php - since your theme doesn't have this file, it points WordPress to it's parent (in this case, Twenty Ten), and WordPress uses the index.php from it.
This is the benefit of Child Themes: You can apply (mainly cosmetic) changes on top of a theme, while leaving it's core functionality untouched.
Now, imagine the Child Theme you're describing: an exact copy of Twenty Ten. Whenever WordPress requests a file (like index.php), it's always available - there's never any need to revert back to Twenty Ten for a file, because for all intents and purposes, your theme is Twenty Ten.
But what if a security hole is found in Twenty Ten's index.php? Automattic sends out an update fixing it, and that's that. But since your Child Theme is just a copy of Twenty Ten, it never receives the update, and you're running code with a known bug.
This creates a security risk, and there are hacker programs out there that just go around looking for known bugs in WordPress sites (according to my server logs, my site gets attacked by these bots at least once a week). So, doing this will put your site at risk of being hacked (how likely it is depends on what bugs are found and how popular your site is, but the risk is there).