Question: **Is an Enterprise Service Bus** (a tool that acts as a mediator, a message broker, a service enabler, schema transformation enhancer, transparent location provider, service aggregator, load balancer, monitor, and all that stuff) **responsible to orchestrate services**?

What about putting an automated business business process with more than thousand steps and dozens of service invocations inside your enterprise service bus?

Would you do it, or would you use a specialist in orchestration such as a BPEL engine?

Please gimme you opinion.

Answer: 
Yes and no. There's a thin, and sometimes indistinguishable line between orchestration and aggregation/service augmentation.

In general, if you've got any long-running or complex business process (process being the key word, although I'm going to avoid defining it) - that's best suited to BPEL.

Simple tasks, such as aggregating the results of three service calls, could and often should be done in an ESB layer.

It's not worth losing too much sleep over, though

Disclaimer: I am an IBM ESB consultant, although I'm not writing this in an official capacity.
Whenever you have two or more services that interact use service orchestrator, i.e. for composition and process control services. If you have esb expose this composition service on esb. Now if you have to compose new service that includes this composition service use orchestrator and again expose on esb.
Use esb as service delivery mechanism and web service broker and proxy. In composing a service orchestrator will use esb to reach interacting services. If these interacting services use incompatible xml schemas esb can transform/map them to common schema in runtime and route service requests based on the content, e.g. namespace.