If we believe that BPM is "the" technology of business (on the basis that "business is about work, and BPM is the main or only technology explicitly about work"), then BPM adoption is very important for business success, at least insofar as business depends on technology.
The assumption of today's question is that BPM technology adoption (defined most broadly as including technology and methodology) is lower than hoped for, or less than expected, or even disappointing. And the answer provided above are terrific.
Here are some additional thoughts as to why BPM technology adoption is lower than we would hope, given the promise:
1) TECHNOLOGY MATURITY -- The sales pitch for BPM is great, draw how you want your business to run, and then simply build out the processes to match. And voila! But the reality of "solving a graph in real time" is that the gap between modeling and execution is wide. And once deployed, if you've added so much execution specific information to the executable that your model is no longer in sync, then for all intents and purposes, you're locked in. There are methodological ways around this, but even then we a long way from our dreams of BPM. The result of the fact that BPM is harder than it will be, eventually, is that only dedicated IT shops, with very strong methodological discipline, patience and good communications between IT and business, are using BPM extensively. (There will be lots of little instances of "workflow" of course where roundtripping is not so much an issue.)
2) GOVERNANCE & ECONOMICS -- The BPM methodologies described above sound a little bit like Soviet-style top-down management. In this case business process becomes an effort of will. "Make it so". But just as Soviet management ostensibly eschewed "motivation" and economics, in favour of will, BPM and process governance typically do the same. Inside the walls of the corporation it's mostly command and control. And that C&C first of all bumps up against the technical complexity of BPM (per point No. 1 above). And then we ask ourselves why particular groups within a corporation may be happy or not with current practices. We can assume that at some level most people are motivated for goodness, and within a corporation, for the success of the corporation. But for a given process, is there motivation for individual groups of production workers, accountants, business analysts, plant managers, line managers, support staff, IT etc., to add to their daily workload while they build a new process, a new process that is personally risky? As well as dauntingly complex? And for the really juicy BPM projects which are cross silo, these concerns are especially acute. It's worth noting that the very centrality of BPM to what we do (i.e. "work") means that BPM impacts corporate team members at the core of their relationship with the employer.
BPM technology will inexorably improve. And given the on-going rationalization of the corporation with new generation business process outsourcing, process governance becomes clearer and easier when what you do is so much more specialized. The BPM business may be a game of inches, but it is growing and will continue to grow, especially in hospitable environments where governance and economics are well managed.
It is said that "software is eating the world". An interesting extension of this question would be "what kind of software" . . . maybe BPM?