From my non-professional point of view: There is the layer of reasoning, where IMHO a utility-based selector fits very well. There is the layer of executing behaviors, where a BT fits well in case that the behavior can be pre-defined, or a planner in case that the behavior is assembled at runtime. (Although the borderlines are blurry; of course, there are "work-arounds" to solve problems of not well fitting kinds in each of the AI solutions.)

Let's use a warrior that becomes facing a wild horde of enemies. A utility-based reasoner investigates some options, one of them being "flee_in_panic". This option occurs to have the highest utility, and hence is selected. The option's action part is in fact a BT sequence node. The encoded behavior is a "drop_weapon" action, followed by a "turn_around" action, followed by a "flee_from" action. While the former 2 actions are more or less direct instructions to the motion / animation layer, the 3rd action is a motion planner node. This node requests a path from the path finder sub-system, and starts executing it. For each path segment the appropriate sub-behavor is selected due to hints given with the path segment.

When looking at such a tree, the reasoning is done on the entirety of options at once, where utility-based selection shines. The designer wants the agent to drop the weapon, rise it hands, turn suddenly around, … hence an a-priori known behavior. Here a BT is useful (but that does not mean that a BT is restricted to fix behaviors; it is just so that a BT is fully pre-defined). Running along a path, however, is depending on the path characteristics which may be known at runtime first. Hence using a more flexible device like a planner seems appropriate.