There are a few ways people tend to use FPGAs:

1) Replace logic gates like AND and OR gates, flip flops, etc. 

2) Perform algorithms in hardware which can be very parallel either with or without a CPU

3) Provide custom I/O devices for a CPU

4) Build custom CPUs

You might think that these are all just applications of #1 and to some extent you'd be right. However, in many cases people use "Intellectual Property" or IP to build up algorithms, custom CPUs, or custom I/O devices without actually worrying about the details. Just like you can use someone's C library in your Visual Basic Program even if you don't need C, IP lets designers share functions with people who might not be able to build them themselves. We won't talk much about that because we want to design!

Another trend is to see FPGAs married with CPUs either on the same board or, in some cases, in the same package. Sometimes, the FPGA has an actual CPU hardwired into the silicon. In other cases, the CPU is "soft" and just consumes some of the resources available to you as an FPGA designer.

A lot of example FPGA projects don't really show the best uses of FPGAs. For example, a fair beginner project might be a simple traffic light with some red, green, and yellow LEDs. But the reality is there is no advantage to using an FPGA for this over a processor. The time scale is relatively long and doesn't need high precision. FPGAs are harder to work with and often take more power than a stand-alone CPU. So you really want to use them where there is a compelling advantage.

For example, suppose you have an industrial process that if any limit switch hits you need to stop immediately. Further, for whatever reason, every switch needs to be separate. So if you have 10 switches you are going to have 10 inputs.

On a CPU, the simple way to do it would be to test each switch in turn. But that's going to be slow because you have to look at switch 1, then switch 2, and so on. Presumably, the CPU is also doing something else.

Another idea would be to get all 10 inputs into a 16-bit word, for example, and test that. That's better, but still doesn't solve the problem of you have to do other things and while you are doing those things, you aren't watching the switches. You'd probably want to make each switch generate an interrupt (or OR them together and use that as an interrupt). That's better, but there are still times when an interrupt won't occur right away, so the timing won't be great. 

Now what if you have 50 inputs? Your timing is probably going to be worse. With an FPGA, you could make each input trigger circuitry and while it won't be instant, it won't matter significantly if you have 10 or 50 inputs. At some point you'll run out of pins, but until then, it won't matter.

In effect, all the switches "run" in parallel. This is useful for processing audio or video, too. Say you have audio buffered at 22 kHz for one second. That's 22,000 samples. You need to do some math operation. A common CPU will do one at a time. If you have threads, you might be able to pretend to do more. Some CPUs have special instructions made to do things in parallel, but maybe not 22,000 at once. With an FPGA of the right size, you could define the math block for one sample, duplicate it 22,000 times and -- with the right memory architecture -- do the processing in what amounts to a blink of time.

So for learning, it doesn't really matter. But in the real world, you want to pick the right tool for the job. FPGAs aren't for everything. But when you need their inherent parallelism, they can be the best -- and most practical -- choice.