There are at least two (conflicting) ways to think about this:
Whether you provide a default depends on the context. If you provide a default, you should be prepared for people to select it even when it's the wrong selection. This is particularly true for user interfaces that require lots of inputs.
For example, my company's application has an online calculator for determining how much money the government will permit them to contribute to their health savings account. The contribution amount depends on whether the employee's health insurance covers just the employee or their entire family. If the employee contributes too much, they will need to go through a tedious process to "undo" their excess contributions. The online calculator asks the employee to specify what kind of health insurance they have. The calculator used to provide a default value, and people tended to use that value without thinking about whether it was appropriate. Eventually we decided to remove the default.
On the other hand, there are times when a default is appropriate. If the default choice is the most likely or the best choice under the circumstances, you can improve usability by saving the user the trouble of selecting that value. This is especially true if the cost of changing your mind later is low. For example, imagine a website for viewing movie trailers. You can view the movie in three different resolutions. The lowest resolutions will download the fastest, which saves money for the website owner, and possibly saves money for the user, too. The cost of switching is low, and the website owner knows that most people prefer to use the lowest resolution, so it makes sense to default to the lowest resolution.
You need a hard-and-fast rule because consistency improves usability. Consistency (always selecting a default radio button, or never selecting a default radio button) leads to fewer surprises, and an object is more usable when you know what to expect out of it.