Desirably an Activity is described using

• one object and
• one verb,
  

so a reader can clearly understand, what happens to what.

If only an object or a verb is used to describe the activity, there will be ways to misunderstand the situation.

"invoice" does not imply whether an invoice is created, processed, payed or sent. Ambiguousness shall always be avoided.

If Subprocesses are used to define abstractions, it is Bad Practice to specify detailed dependencies concerning the Subprocess. The message flow in this example should be simplified int the given model and/or specified in detail in a separate model.

This model confuses because of bad abstractions.

Even if the seemingly same activity is executed by different Roles, every "instance" of the Activity has to be modeled separately.

This modeling is not correct. Pools and Lanes are used to allocate Activities to Roles, the example conflicts with this concept

If more than one role is involved in the execution of an Activity, the Activity should be split and interaction modeled with Message Flow.

In this case it would be valid to leave Lanes out, but it would not denote in any way how Manager and Employee are involved in the Activity.