@thinkdoom It’s true that those pieces say different things, but that’s because they refer to different things. The first one:
Refers to embedded subprocesses (with a solid border) within a process. Since the activation of these is part of the regular control flow (connected to other flow nodes before and after), a timer start event doesn’t really make sense. The subprocess is simply started as soon as a token arrives to it. Nothing prevents you from delaying that actual start though; you could have an intermediate timer event immediately after the none start event, but that would simply cause a pause after the subprocess was started straight away.
The second quote:
Refers to event subprocesses, which activate an event subscription immediately once the scope they belong to is entered and wait for the occurrence of their start event. They are not connected to the rest of the flow they are positioned in and due to the event subscription it makes more sense to have other options for the start event, such as a timer.
In your model, using the timer start event this way is most likely correct for what you want to achieve, but it seems you are surprised that the timer interrupted the main flow. This is because the timer start event you modelled is of the interrupting kind. In Camunda Modeler, you will find there is an option to switch the type to a timer start event that is non-interrupting (use the little spanner). With that configuration, if the timer fires (which can happen while the main flow is in any state (in the current model)), an additional token will be created for the event subprocess, while the main flow srays exactly where it is.