One thing to note is that in the UML Superstructure, there is no mention of activities within activities. Activities contain ActivityNodes, ActivityEdges, ActivityGroups ("a ... grouping construct for nodes and edges"), ActivityPartitions (a kind of ActivityGroup), StructuredActivityNodes, and Variables.
Activities do not contain other activities. That EA allows one to embed activities is not good UML.
The CallBehaviorAction is how one invokes another activity.
An analogy is to think of activities as being equivalent to callable programs, and a CallBehaviorAction is a call to the Activity (hence the name). If we ignore some better-forgotten programming constructs of the past, it doesn't make much sense for flow to go between a callable program and another callable program without a call.
Interestingly, if you do embed Activities within activities in EA, you get effects analogous to those one might expect with executing callable code inline in some ancient programming language - the constructs that make it OK to use inline make reuse difficult (or, conversely, the constructs that enable the code to be called make its inline use difficult). If you have two activities linked by an edge in one activity diagram, those links persist when you copy the activites to another activity diagram.
It might help to notice that unlike (most) other diagrams, an activity shares the same boundaries as its diagram. One of the problems with the EA implementation is that its easy to create a diagram without the activity.
