I wouldnt say they are my definition :-), it is the standard one. Re-defining same terminology as something else or making them open to interpretation, is detrimental. More so when the point of view could be contentious.

Ideally definitions shouldnt only be essentially the same (for some values of essence), but obviously/unraguably the same. Or else we discuss definitions :-)

The point I was trying to make is simple. By conventional terminology: Concurrency deals with semantics, parallelism deals with execution. I dont see how

  parallelism as splitting a computation into many independent tasks which interact very little,
  and concurrency as modifying things from different threads/processes/tasklets/whatever without
  incurring in hairy bugs.

translates into the standard definition. What the author describes as parallelism could easily be concurrency if the split happens at the semantic level.

BTW concurrency needn't have any explicit synchronization primitives at all and needn't have anything to do with synchronized clocks. Semantics does not care about execution or clocks it cares only about meaning. Since parallelism deals with execution, there clocks could become relevant.

Consider list comprehension in Python. Its a concurrency primitive. But whether the elements of the list are computed simultaneously, depends on how the Python code is executed and hence an issue of parallelism.

"Concurrent code" and "parallel code" terminology can also be confusing. If a piece of code describes/defines things you want to compute, then it can only be concurrent and not parallel. But if the code also describes how it is going to be executed in the hardware then it could be called parallel. So I am not confident of the view

  threads are meant for concurrency and not parallelism

I have no difficulty in accepting that threads are not always the right abstraction. Shared mutable state is a significant problem.

But forwarding that argument by conflating conventional terminology as was done in the article hardly helps.