Often, decomposition is based on areas of domain or functionality. There are some downsides to doing it this way. The method in the book proposes it be based on areas of volatility instead. As an example, imagine writing a piece of software for FedEx shipping. What would change to use that same software for UPS instead? That may identify some areas of volatility. If you can plan that something might change, you can limit the ripple effect of those changes in future. Just an example of one benefit of doing it this way. The book explains some of how to approach designing this way.
Another point: Architecture is not just about designing the software. It is also designing the project to build that software. This involves things like critical paths, staffing, risk management, etc. Understanding these is important if you want to be able to deliver on time and on budget.