Mathematically, a block cipher is just a keyed pseudorandom permutation family on the set $\{0,1\}^n$ of $n$-bit blocks. (In practice, we usually also require an efficient way to compute the inverse permutation.) A block cipher on its own is not very useful for practical cryptography, at least unless you just happen to need to encrypt small messages that each fit into a single block.
However, it turns out that block ciphers are extremely versatile building blocks for constructing other cryptographic tools: once you have a good block cipher, you can easily build anything from stream ciphers to hash functions, message authentication codes, key derivation functions, pseudorandom number generators, entropy pools, etc. based on just one block cipher.
Not all of these applications necessarily need a block cipher; for example, many of them could be based on any pseudorandom function which need not be a permutation (but, conveniently, there's a lemma that says a pseudorandom permutation will, nonetheless, work). Also, many of the constructions are indirect; for example, you can construct a key derivation function from a message authentication code, which you can construct from a hash function, which you can — but don't have to — construct from a block cipher. But still, if you have a block cipher, you can build all the rest out of it.
Furthermore, these constructions typically come with (conditional) security proofs that reduce the security of the constructed functions to that of the underlying block cipher. Thus, you don't need to carry out the laborious and unreliable task of cryptanalyzing each of these functions separately — instead, you're free to concentrate all your efforts on the block cipher, knowing that any confidence you'll have on the security of the block cipher directly translates into confidence on all the functions based on it.
Obviously, all this is very convenient if you're, say, working on a small embedded platform where including efficient and secure code for lots of separate crypto primitives could be difficult and expensive. But even if you're not on such a constrained platform, writing and analyzing low-level crypto code can be laborious due to the need to pay attention to things like side-channel attacks. It's easier to restrict yourself to a limited number of low-level building blocks and to build everything you need out of those.
Also, even on fast platforms with lots of memory, like desktop CPUs, implementing low-level crypto operations directly in hardware can be much faster than doing them in software — but it's not practical to do that for more than a few of them. Due to their versatility, block ciphers are excellent candidates for hardware implementation (as in the AES instruction set for modern x86 CPUs).
What about stream ciphers, then?
Mathematically, a stream cipher — in the most general sense of the term — is also a keyed invertible pseudorandom function family, but on the set $\{0,1\}^*$ of arbitrary-length bitstrings rather than on blocks of limited length.
(There are some subtleties here; for example, most stream cipher constructions require the input to include a unique nonce value, and do not guarantee security — in the sense of indistinguishability from a truly random function — if the same nonce is used for two different inputs. Also, as there is no uniform distribution on invertible functions from $\{0,1\}^*$ to itself to choose random functions from, we need to define carefully just what it means for a stream cipher to look "indistinguishable from random", and this definition does have practical security implications — for example, most stream ciphers leak the length of the message. Practically, we usually also require that stream ciphers, in fact, be "streaming", in the sense that arbitrarily long input bitstreams can be encrypted — and decrypted — using only constant storage and time linear in the message length.)
Of course, stream ciphers are much more immediately useful than block ciphers: you can use them directly to encrypt messages of any length. However, it turns out that they're also much less useful as building blocks for other cryptographic tools: if you have a block cipher, you can easily turn it into a stream cipher, whereas turning an arbitrary stream cipher into a block cipher is difficult if not impossible.
So why do people bother designing dedicated stream ciphers at all, then, if block ciphers can do the job just as well? Mostly, the reason is speed: sometimes, you need a fast cipher to encrypt lots of data, and there are some really fast dedicated stream cipher designs out there. Some of these designs are also designed to be very compact to implement, either in software or hardware or both, so that if you really only need a stream cipher, you can save on code/circuit size by using one of those ciphers instead of a general block cipher based one.
However, what you gain in speed and compactness, you lose in versatility. For example, there doesn't seem to be any simple way to make a hash function out of a stream cipher, so if you need one of those (and you often do, because hash functions, besides being useful on their own, are also common building blocks for other crypto tools), you'll have to implement them separately. And, guess what, most hash functions are based on block ciphers, so if you have one, you might as well reuse the same block cipher for encryption too (unless you really need the raw speed of the dedicated stream cipher).
