I agree with your points above. I just think the article took a wrong turn when it flipped to 'agile' chest thumping. Here he makes the mistake of not recognizing the scope of effort required to react. Building out a class or function may require only a few minutes or perhaps hours if it is determined that it is really needed. The same time frame doesn't apply to building out and ESB where you are now talking months (if not longer). Larger infrastructure changes must be planned to stay just ahead of need because you will have little luck getting a project to just wait while you build out the infrastructure.

More thoughts on this post

All true. Just one small, if academic, point. The ESB is part of the SOA pattern and not necessarily a "mere instance of technology." As a practical matter, I understand only too well that ESBs like most all services in a SOA will be instances of technology - aka products. Thnx for highlighting this note.

I think of ESBs as similar to appservers. The reason you need them is because they provide the management and governance capabilities. It will be pretty simplistic to think of ESBs as just a technology showpiece. I do not buy the argument that they are pretty useless upfront in a SOA shift. Infact they make perfect sense if you can keep the costs low. Or you could end of with a hodge podge of services derailing your SOA efforts.

I think the real issue with implementing SOA in an organisation is the fact that it is never green fields. You are generally inheriting a couple of mainframe, newer web, Java apps and whatever else the organisation has built over the last 15 years. Couple that with the risk-averseness of management and usually the best way to do things is in small short phases. Approach then becomes - implement the ESB now, do some small integration projects, gain management confidence and slowly build out the architecture over time.
Its definitely not ideal, but unfortunately it is usually the way it needs to be done if it is ever going to get off the ground.