I can give you another example. Consider you have some ecommerce system. You would have products there, however products will be part of at least two different domains:
- Product catalog, where you keep your product description and all attributes
- Inventory, where you have product stock level
If you have one bounded context for both domains, your solution can quickly become a big ball of mud because you will start cross referencing it. At the end you will not have two domains anymore. Your product inventory will be spoiled with product catalog references and vice versa. As the result of this you will not be able to change one domain without touching another even you fully realize this is not required. Your models become dependant on each other and tightly coupled, and dependant in a bad way - being dependant on implementation.
If you, however, have two bounded context, all changes you do in one domain will not affect the other as soon as you keep your communication channels clear. It will mean you need to have data duplication but this is the least cost to pay for losely coupled component based application. Your domains can talk to each other using domain events. Even if you do not plan to have SOA based application in the beginning you will be able to scale up to that level when you need with relatively low effort since you just change the transport for your domain events, leaving the idea behind it intact.