Instead of thinking of Event Sourcing as being a purely design and technical issue, think of it as having a clear business benefit instead. For instance, if I'm using Martin Fowler's shipping example, I might have a business reason for wanting to know where a ship was on a given day.
It's possible that you don't have this business reason yet. Is there a possibility that you will have that reason, some time in the future? Some business requirements aren't just about the functionality you need now, but about keeping options open (almost the opposite of YAGNI). You can look at Chris Matts' work on Real Options to find out more.
Now that you have established the business benefit, think of TDD and BDD as helping you to establish which of those classes are responsible for that benefit. TDD and BDD don't help you to drive out good design as much as steer you away from the bad ones. They make you consider the responsibility of each of your classes, provide an example of how to use it thereby ensuring usable code, and ensure that each aspect of the class is genuinely valuable. You can still gain these benefits and come up with your own architectural requirements too.
Rather than trying to get architecture right, think about the cost of getting it wrong. Would it really be hard to adopt event sourcing later? If you discovered that the cost was prohibitive and the business didn't need it, how hard would it be to return to state-based persistence? As Chris has said in the past, if you don't know which technology is right, don't pick the right technology. Pick the one that's easy to change. It's either right already, or you'll have more information later that will help you to make better decisions. Your product owner or business expert may also be able to help decide whether the business benefit is worth paying for now.