TL;DR -- for most folks "low code" usually means "little/no typing" while "declarative" means something a little different. I'd agree that what Salesforce allows is not "declarative development."
I also agree mostly with Robert's answers, with a few small differences. FWIW, the terms "imperative" vs. "declarative" go back to early programming languages.
"Imperative" programming languages were used to describe languages that essentially mimicked what you would do at the machine level, i.e. execute a list of commands that computed a value, assigned a value to a storage location, sent a value to an output device, etc. Statements were executed in a sequence with branch points and conditions to implement loops, if-then-else structures, and so on. Languages like Fortran, COBOL, ALGOL, C, and Pascal were all imperative. They were "imperative" because you specified how the program worked, sometimes in ways that very closely matched what happened at the machine level (i.e. C).
"Declarative" programming languages were supposed to be more abstract, and specified more what you wanted computed and less how it was done. Languages like SNOBOL and Prolog were this way. Such languages generally were interpreted because they required large compute engines underneath them to execute. Later it became common to compile them into executable images in which the compute engine became part of the image.
The dichotomy between the two terms fails somewhat since in both cases you need to know how the elements of the programming language will be executed to know how you should construct your program.
I haven't programmed in Salesforce, but I have programmed in BPEL, and it's very similar in appearance. You basically draw flowcharts with relatively small amounts of typing. This approach goes back to the early graphical programming languages that were coming out in the 1980s. It's "low code" in the sense you spend more time dragging and dropping shapes and less time typing programming statements. I'd argue that it's still imperative because the flowchart you're constructing has the same elements as an imperative programming language (sequence of statements, computing values, assigning values, branch points, etc.).
There are some more declarative graphical programming systems. I'm currently using SnapLogic, an iPaaS, which reminds me a lot of APL or SNOBOL in the way you have to think to construct your programs. It's nice in that you don't have to specify certain things (i.e. looping over a list of data items, which happens implicitly), but it can be more challenging to do things that are, at least to me, straightforward in a more imperative approach.
Ultimately I agree with Robert -- the important question is less, "What do you call this?" and more "How easy is it get things done in it?"