Thanks for stating this so clearly. I am always confused why data flow frameworks, DSLs, or other syntactic sugar inevitably gets entangled with functional programming. Once more logic is in stateless functions and easy to test and compose (as you stated), one can gradually introduce layers, sugar, and abstraction (should the team choose)
On the contrary, that is exactly what those patterns are for, indeed it's the only legitimate justification for using them! If you can make your functions simple and stateless without using "fancy" patterns you should do so. The point of things like monads is to make it possible to do that with functions that do otherwise effectful things.
If your functions are "stateless" (by which I assume you mean they don't depend on or modify outside state), then they are pure functions so... that's exactly FP?
That’s my point. FP can be as simple as that, and applied to any codebase. It’s all the extra stuff (which is good) that typically “defines” FP that scares people away, and keeps them from seeing the utility of a simple, pure function.
This can be done in any language without introducing “foreign” FP patterns and instantly makes code easier to understand and test.