Control Flow obvious recognizable. Using Gateways leads to easier visually recognizable context.

Multiple in- and outgoing Edged on Activities should normally be avoided. The modeler often does not know what is implied by this modeling, he models wrong.

Control Flow cannot be synchronized, besides Activities can be exectued more than once (which may not be wanted).

To avoid such situations, it is better to use Gateways. They make the model clearer and easier understandable.

One Gateway shall be used to either Split or Join control flow.

The Gateways do not differ visually, so it is Best Practice to model Gateways with either multiple ingoing or multiple outgoing Edges.

Though this modeling is syntactically correct, it complicates the readability of the model. If there are such "double-defined" Gateways the reader may misunderstand certain things.

An automatic Transformation for example to BPEL is not possible for this model.

Splits shall be Joined equivalently (balanced Gateways).

Otherwise there may be semantic mistakes and the readability may decrease.

Bad-Practice-Pendant for Joining equivalently.

Problems with automatic Transformation to BPEL preassigned.

To Join control flow the same type of Gateway shall be used as for Splitting.

It is possible to not Join splitted control flow, this is syntactically as well as semantically absolutely correct. If it should be joined, then only with the same type of Gateway.

Small but crucial difference:

This model is semantically not correct as an AND-Join follows an XOR-Split. The XOR-Split does not necessarily need an XOR-Join, but an AND-Join is definitively wrong. This also applies to all the other Gateways.