You are wrong when you suggest this code is 100% insecure!
SSH opens an encrypted session between the SSH client (computer you are sitting at) and the SSH server (remote SSH server.) In most cases, the client and server are separated by at least one firewall, between 2 trusted networks.
When you use the script supplied in the article, the client (computer you are sitting in front of) opens an encrypted SSH session to the target (remote SSH server.)
The -L option tells the SSH client on your workstation to listen for a connection to localhost on port 10548. When the client connects to localhost 10548 after establishing the SSH session, the SSH client forwards the connection through the encrypted SSH tunnel to the target SSH server.
When the target SSH server receives the forwarded port request through the encrypted SSH session, the target SSH server forwards unencrypted traffic destined for 548 to the AFP host (host defined between the listen port and destination port separated by :.
If the remote host accepting the AFP traffic is on the same network as the destination SSH server and behind a firewall, the connection has been secured because the vulnerable traffic was encrypted while in transit over the Internet (between the two trusted networks.)
If you can't trust the destination network, then you shouldn't even connect with SSH.
You may want to do some more research. To test this, block TCP port 548 on your target network, then forward TCP 548 to a destination behind your target network. Connect to localhost on TCP 548 and see that you get a connection. If you do this correctly, you should mount a share on the target network through the SSH tunnel. If you can mount the AFP share via localhost, then you have proven it was through the SSH tunnel because the firewall rule blocks the traffic from the Internet. If the traffic came through the SSH tunnel, it was encrypted between the two networks. This isn't rocket science!