The answer is usually "create a field in the same object." This is sort of implied by the "rules" of database normalization (the First Normal Form, Second Normal Form, etc). You can do a search to learn more, but basically speaking, all data that isn't duplicated belongs in the same table, and data that would be duplicated should be in separate tables so they are no longer duplicated.
However, there are exceptions to the rules. For example, you may have a double-book accounting system, where each debit has an associated credit. In this case, each record will have a 1:1 relationship, but you need the data to roll up to each account separately.
Or, you might find that you need more than the maximum number of allowed relationships or fields, so you need to split the table (we actually ran in to this problem in our production org!). Or, it might be a matter of security, where you need some of the data hidden from some users, and for some reason, field level security won't work. There are at least several good reasons why a custom field simply won't work.
Using a separate custom object has several penalties. First, more storage will be used (2kb per record), so you'll double up on the storage you're using with the latter design. Second, you're limited to the number of relationships you can create on a single object. Third, this design means more data entry screens or custom code to meld the data into one view/edit mode.
So, in summary, the answer is "usually custom fields, unless you have a specific reason otherwise."