Reuse has been the battle cry for many SOA proponents in the recent past. You can't blame them -- that's how SOA has been sold. Reuse, however, is just a small component of the value of SOA, and too much focus on reuse can lead to misalignment of priorities and a resulting bad architecture.
We've been doing SOA long enough to know that the main benefits are around the core architecture and the ability for that architecture to change to accommodate business. Good architecture, including SOA, is not something you come by accidentally; it takes careful planning and a lot of work to get to a healthy state.
[ There is still a lot of misinformation out there about SOA. Read "4 SOA myths busted." | Effective architecture is key to business flexibility, agility, and efficiency. Keep up on developments in SOA with InfoWorld's Technology: Architecture newsletter. ]
When the focus is on reuse within the context of SOA, there seems to be a misalignment of what needs to get done to create an SOA. What should be an architecture problem becomes a programming problem, and that's not going to get you where you need to go. While you may build a mechanism to promote and facilitate reuse, the value of SOA is severely diluted if that's the core focus.
Don't get me wrong -- reuse is a requirement to get to architectural agility, but if reuse is the only objective than you're going to find it hard to map out a path to agility. Architectural agility requires that you address the architecture holistically, from the data to the service to the process layer. Agility, as a value of SOA, requires that you place volatility into a configuration layer, where changes to the architecture do not drive waves of reprogramming, testing, and deployment.
I suspect the value of reuse will continue to drive SOA, but it will also drive many in the wrong direction. Make sure you focus on what's important, versus what seems to be obvious. There is a difference.