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.
Yes orchestration is a responsibility, in most cases, of the ESB. Or, alternatively, if you draw a line between ESB infra and orchestration infra, then you are doing so on a physical level for performance reasons, not for logical attribution of responsibility. 

You have 2 choices - when, for example, an HR system receives a new employee - where do you place the business logic that says "the compliance department will need to approve and check first, and then if that's ok, the HR department will need to finalise the hire, then the accounting department will need a new entry, and then the payroll system will need updating, and if that fails, then we'll need to send an email to HR"? If all business processes are considered 'owned' by the initiating dept/application, then the overall system that is the enterprise becomes complex, with disparate orchestration systems.

The second choice is centralise the orchestration, essentially making it a logical partner of the messaging platform. If you choose to see these as separate artifacts, that is up to you, but it is equally valid to described both as ESB.