That’s a great rule of thumb to quickly identify whether some new syntax is more likely to be imperative or declarative, but it’s not a great explanation of what the two terms mean for someone new to the terms. A banana doesn’t have control flow but it’s definitely not a declarative programming language.
The "has control flow" vs "doesn't have control flow" description is a bad one, an attempt to reduce "declarative vs imperative" down to syntax instead of semantics. The parent to my comment is still in imperative style, despite having no control flow: It's specifying what actions to take to reach the desired outcome ("eat"). Declarative is describing the desired outcome, then letting the system figure out how to get there.
When you write an SQL query, you're not describing steps to take, you're describing the outcome you want (what rows and fields from which tables and how those tables relate to each other). The query engine then takes that description and figures out how to actually do the query (what indices to use, in what order, how to actually loop/hash/map/scan the tables and indices, etc). This is what EXPLAIN shows you, the actual imperative plan the query engine came up with given the declarative query you gave it.
Another common example would be CSS: It's all about describing the desired result and spatial relationships between elements, then the CSS engine takes those rules and figures out how to actually get those elements to do what you want. Like something as seemingly simple as "float: left" - for the text to wrap around it, the engine has to deal with the image size, position, font and font size, figuring out when to wrap the text, height of the font, which line of text is greater than the image height, etc. The engine does a lot of work figuring out the steps to take to get the result you've described.