I would say that the SSH client and server "getting out of the way" is a very bad way to describe dynamic port forwarding, and might be the result of several writers repeating a badly written or over-simplified description they've probably been taught at some point.
As others have described, SOCKS is used as a standardized way to tell any compatible TCP proxy where the proxied connection should go. Essentially, the SOCKS protocol is like using an old manually-switched telephone: "Operator, connect me to Town X phone number Y, please!" After doing exactly that, the operator is not (supposed to be) listening in on the connection and you can talk to the person on the other end using any language you want.
In SSH dynamic forwarding, the application client opens a TCP connection to the dynamic forwarding port (the SOCKS server port), makes a standard SOCKS request to be connected to a particular IP address and port, and can then resume using whatever protocol it would use natively over that TCP connection. It needs to be able to make the initial SOCKS request, but it doesn't need to know anything further. (There may be some minor SOCKS-specific thing at the end of the connection, but otherwise the forwarded connection will be entirely transparent and protocol-neutral as far as the endpoints are concerned.)
The application server at the other end sees just a plain old TCP connection from the SSH server: it doesn't need to know that the connection is being forwarded, nor that a SOCKS protocol is involved at the client end.
(When your phone rings and you answer it, you would not need to do anything special even if the call would happen to come from a museum of technology with a functional manual telephone exchange with an outgoing line to the landline phone network.)
So, in strict client/server terms, when the dynamic forwarding functionality is activated, a SSH client will also act as a SOCKS server with the specific additional property that all the connections using the SOCKS server will be passed within the encrypted SSH tunnel to the remote SSH server and resume as regular TCP connections from there on.
Or, put in another way, the combination of the SSH client with dynamic forwarding enabled + SSH connection + SSH server will act as a SOCKS proxy that's been stretched over the distance covered by the SSH connection, so that the inbound side of the SOCKS proxy is co-located with the SSH client, the outbound side is at the SSH server, and what happens in between looks like non-descript encrypted SSH traffic to outside observers.
Note that only the hop between the SSH client and the SSH server will be secured by SSH. But the hop between the application client and the SSH client/SOCKS server is normally within a single host. The only remaining part that may be unencrypted (unless the application protocol includes its own encryption) is the hop between the SSH server and the application server.
