Flowchart diagrams vs. UML activity diagrams

It might seem as a preference, but if we have a standardized language for describing software systems, Why do we use something else? This can lead to bad habit of overusing flowcharts. Activity diagrams are really simple. But if you decide to describe a more complicated aspect of the system or try to change the part you are describing, you might have to switch anyway. So just use UML and prevent confusion in the future.

According to the Agile Modeling site:

In many ways UML activity diagrams are the object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured development.

From IBM:

However, flow charts do not include And states, and flow charts for operations cannot receive events.

Probably this is why flow charts are easier to understand because activity diagrams have the notion of object-oriented development and concurrency.

As you note, Activity diagrams inherently can include concurrency and timing. If you look at this example cribbed from Wikipedia, shown below, you can observe the section with two heavy horizontal bars, and two parallel activities of "present idea" and "record idea". That is read as "start these activities in parallel, and continue only when both are complete." Flowcharts can't express this within the notation.

Practically, using activity diagrams lets you think clearly about concurrent processes. I think you'll find that anyone who can read a flowchart will quickly adapt.

Activity diagram by ​spanish Wikipedia user Gwaur CC BY-SA 3.0, via Wikimedia Commons: