In addition to collision and preimage attacks, there is also the problem of length-extension attacks (which I think of as the "real" reason for this property of SHA3).

If you have a hash function $H$ then it is tempting to treat $H(k,m)$ as a MAC of $m$, with secret key $k$.
Unfortunately, this does not lead to a secure MAC if you are using the previous generation (SHA1, SHA2) of hash functions.

Length extension attacks happen precisely because the hash function outputs its **entire internal state.**
The idea behind length extension attacks is the following:
if $m$ is a prefix of $m'$ then the output $H(k,m)$ occurs as the internal state when computing $H(k,m')$.
In fact, since $H(k,m)$ is the *entire* internal state at some point, then you can compute $H(k,m')$ if you know $H(k,m)$ -- even if you don't know $k$!
This violates the security property you would want from a MAC (learning the MAC of $m$ shouldn't help you predict the MAC of a different $m'$, even if $m$ is a prefix of $m'$).
(Here I am glossing over the issues of length-padding, which don't present a significant barrier to the kind of attack I am sketching.)

During the SHA3 competition, most submissions were designed to be resistant to length-extension attacks.
The way to do this is with a so-called "wide pipe" construction: simply make the internal state larger than the output.
Put differently, the hash should only output part of its internal state at the end of the computation.
If you do that, then $H(k,m)$ will not contain everything necessary to compute $H(k,m')$, and this thwarts the length-extension attack.