To complement poncho's answer: from a theoretical point of view, as poncho pointed out if it can be broken in polynomial time, then this requires only polynomial space, hence considering only time in security analysis makes perfect sense if one only cares about asymptotic security ('polynomial' versus 'superpolynomial'). However, your question becomes particularly interesting when one consider the concrete security of a cryptographic primitive.
To give a simple example, suppose that you have an encryption for which a known attack recovers the key in time $2^{64}$. Should you use this encryption scheme? The standard answer would be essentially no: $2^{64}$ is not out of reach for today's computational power. But looking more closely, considerations about space do in fact matter a lot here: if the best key-recovery attack requires time $2^{64}$ and space (say) $2^{10}$, it's obviously insecure. But it might be that the best known attack requires both time and space $2^{64}$. This is important: space is way more costly than time in practice. Doing $2^{64}$ operations can be envisioned; storing $2^{64}$ bits of data is considerably more involved (I won't make precise guesses about how feasible it could be nowadays - but you get the point).
In fact, until quite recently, the importance of taking memory cost into account when estimating security was somewhat overlook in the cryptographic community. This was recently addressed in a very cool paper. They make the following observation: often, to argue that a primitive A is as secure as a primitive B, one uses a cryptographic reduction, showing that an algorithm breaking A in time $t$ can be converted into an algorithm breaking B in time $t'$, where $t'$ is "not so much larger" than $t$. But if the reduction is memory-loose, it might be that the algorithm breaking A in time $t$ with memory $m$ leads to an algorithm breaking B in time $t'$ using a memory $m'$ much larger than $m$. Now, if $m'$ is too large, then your reduction might not in fact give you any good security guarantee for A: it might be infeasible to concretely break B using this algorithm if $m'$ is huge, even though it could be feasible to concretely break A with memory $m$, hence one cannot say that "if it's infeasible to break B, then it's infeasible to break A", while this was the all point of the reduction. The paper goes on with defining memory-tight reduction, which preserve as much as possible the memory cost of the algorithm in the reduction, and initiate a systematic study of which reductions in cryptography are memory-tight.
