Consider an embedded application with both a discrete processor(ARM, AVR, PIC, etc) and an FPGA to offload some of the work or interface with specific hardware. Assuming there are sufficient resources in the FPGA to fit a soft core equivalent of the external processor, what are the advantages of using a hard processor instead of a soft core?
Generally speaking, a hard core will run faster, use less power, and will use less chip area.
That may mean that it's cheaper or better to use a smaller FPGA and a hard processor (either on one chip or on two).
Some FPGAs have hard cores on chip (for example, the Xilinx Zynq series), so you can use one or both of the two hard ARM9 cores, and/or you could implement a PicoBlaze or MicroBlaze soft (or some other type) processor.
There are also most likely business differences associated with licensing IP for a soft core compatible with (say) an ARM toolchain.
Another reason that an external processor is sometimes used is that it may be connected to an external interface such as USB or Ethernet and permit product update via a remote download. In these cases the external processor can receive a new FPGA program data file and commit to the FPGA subsystem to implement an update of the FPGA design content. (That might be an update directly to the FPGA or it may be an update to a serial FLASH chip that is interconnected with the FPGA's power-on load scheme.
Some of the hard core processors have a more mature development environment when it comes to debugging etc. You can find more programmers that are familiar with the tool chain. On the other hand you might be able to save some space on PCB and a reduced BOM complexity using only a FPGA. It is quite easy to develop a system (FPGA with a SPI-memory) with a bootloader that you can use to upgrade the system in a secure way without using an external processor.
Different tasks require different type of tools. You could force the workload of one kind of tool onto another, but over time it tends to become an inefficient way of doing things. In this specific instance, there are plenty of things which are simply easier to do on a processor. You just have to write the requisite code in a relatively comfortable language like C and have a mature toolchain that can compile it. If you wanted to do the same thing on an FPGA, you're starting at a much lower level and first have to design (or otherwise obtain the design for) a processor core. If the bulk of what you need to do needs to be done by the FPGA, and the processor ends up doing very little, you could invest the effort into removing the processor and wedging the core itself into the FPGA. Similarly, the reverse is possible. However, in practice, you usually end up having the work more equally split between the two.
It's useful to understand, also, what FPGAs were originally used for. They were (and in many ways still are), generic pieces of hardware which can be used to try out new core designs and specialized circuits with the intention of ultimately turning the designs into ASICs. The reason you're able to ask the question now is because the economics have shifted somewhat in terms of pricing, and there are many applications nowadays which are specific enough to not need the high volumes to warrant production of an ASIC. Still, when there is an ASIC (or even a generic processor), it often proves cheaper, faster, and more efficient in terms of cost, development time, and needed skills to use a combination of an FPGA, ASICs, and a processor than it would be to push everything into an FPGA.