Functional Programming is a model of computation. It is computation without mutation (which would be imperative) and without backtracking (which would be logic-based).

I see your point, but personally would just say that the boundaries are fuzzy. Trying to narrow them excludes counterexamples -- Lisp doesn't restrict mutability in the vein of Haskell or Clojure, and logic programming modules are available for most lispy languages I've seen.

I've seen it argued (forget where; likely by Hickey) that FP is a moving target. Once upon a time, lambda style was enough. Now you're expected to also have some mix of: lexical closures, immutability-by-default, pattern matching, some amount of algebraic reasoning, and maybe other things. Homoiconicity and macros aren't a requirement, but I think they're a good FP indicator. Point-free style also strikes me as a good indicator, though ironically Backus's point-free FP language is not "FP" by today's standards.

So to me, a language that encourages one to organize code around (mostly pure) functions is "functional" enough, but bearing in mind that the different camps do things fairly differently.

OOP has the benefit of a shorter history, but it's still fuzzy, hence Alan Kay's quip "I can tell you that C++ wasn't what I had in mind." Taking your example of unrelated modules calling each other directly: the presence of that smell in a codebase doesn't mean the language can't be OO. Again, it seems better to whitelist: "does the language encourage me to organize code around classes / prototypes?"

Effectively writing functional code, then, still requires you to make a plan for your software system's architecture beyond "functional design".

Agreed... writing your functions as if a queue sits between them is something I saw recently that comes to mind. Paradigms might inform architectures, but it seems clear enough to me that they're separate concepts.