In terms of security strength, Is there any difference in using the SHA-256 algorithm vs using any random 256 bits of the output of the SHA-512 algorithm?
Similarly, what is the security difference between using SHA-224 and using any random 224 bits of the SHA-256 output?
SHA-512 truncated to 256 bits is as safe as SHA-256 as far as we know. The NIST did basically that with SHA-512/256 introduced March 2012 in FIPS 180-4 (because it is faster than SHA-256 when implemented in software on many 64-bit CPUs). SHA-224 is just as safe as using 224 bits of SHA-256, because that's basically how SHA-224 is constructed. What bits are kept (provided that's fixed) is immaterial to security, but for compliance to NIST specification, the left bits shall be kept.
As stated in this other answer, in the general case of a hash function only assumed to be collision-resistant or preimage-resistant, restricting its output can make it entirely insecure. A trivial example is the 512-bit function obtained by appending 256 zeros to the output of SHA-256, which is both collision-resistant and preimage-resistant, but trivially insecure when restricted to its 256 right bits.
The stated design goal of SHA-2 functions are preimage-resistance and collision-resistance: "The hash algorithms specified in this Standard are called secure because, for a given algorithm, it is computationally infeasible 1) to find a message that corresponds to a given message digest, or 2) to find two different messages that produce the same message digest". Therefore, truncation of SHA-2 functions is not playing by the book.
Update: FIPS 180-4, which defines SHA-2 functions SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256, explicitly endorses truncation in its section 7: "Some application may require a hash function with a message digest length different than those provided by the hash functions in this Standard. In such cases, a truncated message digest may be used, whereby a hash function with a larger message digest length is applied to the data to be hashed, and the resulting message digest is truncated by selecting an appropriate number of the leftmost bits".
Truncation of SHA-2 functions is safe as far as we know. That's the very principle used to construct SHA-224 from a slight variant of SHA-256, as well as SHA-384, SHA-512/224, and SHA-512/256 from a slight variant of SHA-512 (the variant being to change the internal initialization vector, in order to avoid that the output of one function reveals bits of the output of another one).
The reason why SHA-2 functions can be safely truncated is that these functions have another unstated design goal, that they reach as far as we know, which is: being computationally indistinguishable from a random function, except for having the length-extension property¹ and being that particular function. That strong property is necessary to be able to use the hash with confidence in proofs of protocols made in the Random Oracle Model, and implies collision-resistance and preimage-resistance (the reverse is not true). Truncation (by keeping any fixed subset of their output bits) of a function indistinguishable from a random function also is indistinguishable from a random function (proof sketch: any hypothetical distinguisher for the truncated function is easily converted into a distinguisher for the original function, with the same effort and advantage).
The principle can be extended to any size; e.g. SHA-512 truncated to 128 bits is, as far as we know, as fine a 128-bit hash as can be (regardless of which bits we keep), and unquestionably much preferable security-wise to MD5 (another 128-bit hash, which collision resistance is badly broken). However, collision for an $n$-bit hash can be found in about $2^{(n/2)+0.33}$ hashes, little memory, and efficient parallelization (see Parallel Collision Search with Cryptanalytic Applications). Hence for 80-bit level security (which has sometime been considered an absolute minimum in the early 2000s, and is to be considered insufficient nowadays absent argument of the contrary), when collision resistance is necessary, we should keep at least 160 bits; and when only preimage-resistance is necessary, we should keep at least 80 bits.
¹ The length-extension property is that given the bitstring $H(m)$, the bit length $\ell$ of bitstring $m$ (but not $m$ itself), and any bitstring $s$, it's possible to efficiently compute $H(m\mathbin\|r_\ell\mathbin\|s)$ where $r_\ell$ is a short, efficiently computed bitstring depending only on $\ell$. Truncation of many bits removes the length-extension property. As noted in this other answer, the length-extension property is an undesired artifact, and the basis of attacks in some contexts; and SHA-512 truncated to 256 bits is safe in such contexts, when as SHA-256 is not.
If we are talking about collision resistance, then - in general for any hash function - using only part of the output may be a problem.
Given an arbitrary collision resistant hash function $H$, such that $H(m)=x||b$ (where b is only a single bit), we construct the hash function $H'$, such that $H'(m)=x$, i.e. it gives the same output as $H$ but without the last bit.
We can prove, that collision resistance of $H$ does not imply collision resistance of $H'$. To do that, we construct a specific collision resistant hash function $H$, such that $H'$ is not collision resistant.
For that we assume existence of a third collision resistant hash function $H''$ and define $H(m||b)=H''(m)||b$. $H$ is still collision resistant, because any collision under $H$ would also yield a collision under $H''$. However it now holds that for any $m\in \{0,1\}^*$ $H'(m||0)=H''(m)=H'(m||1)$ and $H'$ is therefore not collision resistant.
This may seem a bit counterintuitive and we assume (and hope) that this is not the case for hash functions that are commonly used (such as SHA-512).
So in short: For a hash function like SHA-512 you will probably be ok, but there is absolutely no guarantee. So don't mess with its output unless it's absolutely necessary and you really know what you are doing. Just use a tool that was made for the job.
The other answers did not mention the Length-Extension attacks on the Merkle–Damgård construction. Length extension is given a hash value $h$;
$$h = \operatorname{SHA-256}(\text{IV},\text{secret_key}\mathbin\|\text{known_data}\mathbin\|pad1)$$
the attackers can produce an extension as;
$$\operatorname{SHA-256}(\text{IV},\text{secret_key}\mathbin\|\text{known_data}\mathbin\| \text{pad1}\mathbin\| \text{appended_data} \mathbin\| \text{pad2})$$
This can be executed by changing the initial values of $\operatorname{SHA-256}$ function to $h$ and hashing the extension.
$$\operatorname{SHA-256}(h, \text{appended_data} \mathbin\| \text{pad2})$$
This attack is first appeared in the Flickr API signature forging over MD5 on Sep. 28, 2009. This is due to the secret at the beginning $$\operatorname{MD5}(\text{SECRET}\mathbin\|\text{message})$$
The truncated version of $\operatorname{SHA-512/256}$ with any selected 256 bits, as pointed another answer, has expected to have the same pre-image, secondary pre-image, and collision resistances with $\operatorname{SHA-256}$. However, the truncation (any selected bits or as the standard) of the $\operatorname{SHA-512/256}$ makes it resistant to length extension attacks, since the attackers must predict the truncated 256-bit in order to extend the hash. Since $\operatorname{SHA-512/256}$ is designed for the 64-bit CPUs as pointed one should go for the $\operatorname{SHA-512/256}$ instead of $\operatorname{SHA-256}$.
In short, If we consider the length extension attack, $\operatorname{SHA-512/256}$ is a better choice.
note: The length extension attack doesn't need the secret_key to execute. It can work without it. Instead of $H(key\mathbin\|\text{message})$ signature we prefer the HMAC - that has no length extension attack and has security proof - and KMAC. The KMAC based on SHA3 which is by design secure against length extension attack and the KMAC construction and proof of it much easier than the HMAC in this case.
