I don't think it's a bug to assume that ssh is normally used with shell accounts. If you can run a shell on the server, you can open TCP ports. Sure, you could argue that defaults should be set to the most security-paranoid values, but that's really not common practice in any project. Yes, the sysadmin should go through the SSH config file, and not just use the defaults that come with the sshd.
I've set up authpf for a couple of clients that want remote access to internal systems without exposing those systems to the outside.
So, in that particular example, ssh port forwarding by default is not desired behavior, because the user isn't granted a full shell for authpf. However, they're considered "trusted" users, so it's not a security problem from a practical standpoint.
However, if I were running a similar service, but more broadly, for "untrusted" users ... then it would be a problem.
While someone might argue then that as a sysadmin I should examine the default settings and modify them according to the needs at hand -- and I would agree -- I could also argue the reverse: that argument is equally valid for disabling ssh port forwarding by default.
In the end, as with most defaults for security-sensitive systems, it should come down to expected behavior. That is, someone who needs ssh port forwarding will know they need it, and can go looking for that particular knob to turn. However, someone who _doesn't_ know about ssh port forwarding should not be expected to go looking for it and disable it in order to not get caught by surprise later on.
