I think all the "yes" answers go a long way to endorsing the idea. But I'm going to throw out the idea that the decision is based on a few questions:
- How do you want to communicate as a team? With 2 developers, you are now a team. How do you want to communicate? Plenty of agile teams live with in person discusions and white board sketches. But they may also go so far as to write things down, especially if it's a bug that won't be high on the priority list for a while.
- How do you want to communicate with your customers? I don't know the answer to this, but if you have any reason to publish bugs (or fixed bugs in a version release document), then you're going to end up writing them down eventually. Might as well pick a low-stress bug management system and be done with it.
- Is there value to preserving history? The answer may be "not right now" but if you think that in the future, you'd like to see the trend of bugs so you can see places that users are having the most problems, or places where you could spend some time checking and reviewing before a major release - then get a bug tracking system. The thing about history is that the day you want the record is not the day you should start keeping records.
IMO, the answers to these questions are more about where you see the product going and how you want to grow your team and less about whether "2 people = reason for bug tracking system". The bigger question is probably "is a bug tracking system worth the time to configure & manage and the cost of purchasing?"