The Ethereum Virtual Machine has three areas where it can store items.
The first is “storage”, where all the contract state variables reside.
Every contract has its own storage and it is persistent between
function calls and quite expensive to use.
The second is “memory”, this is used to hold temporary values. It is
erased between (external) function calls and is cheaper to use.
The third one is the stack, which is used to hold small local
variables. It is almost free to use, but can only hold a limited
amount of values.
For almost all types, you cannot specify where they should be stored,
because they are copied everytime they are used.
The types where the so-called storage location is important are
structs and arrays. If you e.g. pass such variables in function calls,
their data is not copied if it can stay in memory or stay in storage.
This means that you can modify their content in the called function
and these modifications will still be visible in the caller.
There are defaults for the storage location depending on which type of
variable it concerns (source):
state variables are always in storage
function arguments are always in memory
local variables of struct, array or mapping type reference storage by default
local variables of value type (i.e. neither array, nor struct nor mapping) are stored in the stack
The FAQ has code samples to help explain further.
Best Answer
It seems to be related to the data type that you're using. As TripleSpeeder noted, only complex data types (arrays and structs) default to storage inside functions, while all others default to memory.
Inside this StackExchange question is a description of the difference between memory and storage. To paraphrase one of the answers:
A consequence of this design difference is that storage is dynamic and memory is not. Because arrays and structs are complex and could be of variable length, they are defaulted to storage, which has this key:value behavior. Simpler variables like bool, uint, et cetera are not variable in length, and are therefore defaulted to memory, which is cheaper than storage. So, think of the design choice as a compromise between flexibility and cost.
It is possible to create memory arrays, but once created they cannot be resized (check out the Allocating Memory Arrays section).