You know the answer is no, but you're asking anyway, because you don't think the existing explanations suffice...?
Not the worst reason to ask a question, gives me an opportunity to yap. :-)
Functional programming in its formal definition is about the idea of designing computational machines whose output is purely "a function of the input to the machine". If you feed the same input into the machine, it will produce the same output. Each input is named explicitly so you know precisely what the dependencies are. A functional programming language enforces this rigorously.
In Rebol you can write things like:
foo: func [value [integer!]] [
return either now/date = 20-Feb-2013 [
value + 1
] [
value
]
]
There's a function that returns its integer input on every day but today, where you get the value plus one. Hence an invisible dependency on the date which is not formally specified as an argument to the function. The sort of thing makes Haskell people and software formalists like myself scream bloody murder. Imperative programming is good for some things but in my worldview, it is carelessly overused. Lots of good research has been done on better methods that apparently haven't been marketed well enough to the kids of today.
I could say Rebol is not functional programming, Q.E.D. and just stop writing here. But you might respond "Fork, you run around like a rabid weasel telling people to look at Rebol, and Douglas Crockford kind of brings it up when he gets a chance also, and you think imperative programming is overused. So there must be a little more to the story?"
Well, yes sort of.
If you spend any time in computer science you learn about things like Turing Tarpits and computability and these sort of principles of equivalences where "if you can connect X to Y then Z will be true". And just as you can write a Haskell implementation in C, and then restrict yourself to only using C calls mapped into the Haskell library, you might claim you're doing "functional programming" and be technically correct.
So if you wanted to say Rebol can be bent to functional programming styles, you might be a pessimist and say "well it's no better than pretending you're doing C when you're actually using such a confined subset of the language that you're using Haskell by proxy". The trick up Rebol's sleeve is how easily you slip from one "dialecting" paradigm to another. Writing a little domain-specific-language that happens to be functional is so easy and natural that it doesn't feel like you're twisting your language out of joint to do it.
Many people mix up Rebol with its most common dialect (the DO dialect) and think "that's what Rebol is". But Rebol's "essence" is more like XML, it's a data exchange format that coincidentally (okay, not coincidentally) has hyper-optimized code focusing on processing it in some certain ways out of the box. For a good background reading on how it beats the pants off XML, see Was XML flawed from the Start by Carl Sassenrath of AmigaOS (and now Rebol) fame.
