Why not? They are general repeatable solution to a commonly occurring problem in software design - ie, a design pattern. You had non-structured code, then people started using small chunks of code that you'd jump to and back from multiple locations. It's a pattern, that just happened to get encoded directly into some languages, just like others (Norvig talks about the levels of implementation in his presentation on the subject: http://www.norvig.com/design-patterns/design-patterns.pdf)
To me, functions alone aren't abstract enough to be considered a design pattern. If they were, any arbitrary chunk of code, however disorganized, could be considered an implementation of that pattern as long as it used functions, which seems counter intuitive.
I think they're just a victim of their own success. Particularly the iterative language concept of 'function' is by no means universal. They were kind of grafted onto mainframe architectures, and even the MIX from the original The Art of Computer Programming used self modifying code to perform subroutine calls.
Functions are an extremely common pattern more or less expected by every language, but I'd definitely call them patterns still.
A function is not a design pattern. A design pattern is a design that solves a problem. Without stating the problem to solve, you have not got a pattern. The OP stated that they used functions to organise their code, so you can imagine some problem that they were solving with functions. For another problem you might solve with functions, I was reminded recently that functions are an implementation of the state monad. If you read up about where you might use the state monad and why you need it, then perhaps you can get a better feeling for why a function is a good implementation of that pattern.
