To be able to run SSH tunneling, you must have an account on the "edge" machine. It is difficult to permit tunneling without giving a complete shell access on that machine. That's a shell as a generic user. Theoretically, Unix-like systems enforce strict security rules with regards to local users, so that giving a shell access to a user is not a big deal. In practice, if your users are potential attackers, this increases the attack surface: you have to worry about what such attackers can do to the edge machine from a shell running on that machine, as opposed to accessing the machine "from the network".
Also, if people from the internal LAN can SSH-connect to the edge machine, they are bound to try it also from the outside (i.e. from their home machine). You may or may not wish to allow that.
The common theme here is that SSH has a kind of all-or-nothing security model: you give access, or not, but it is not easy to enforce a restricted access ("you may connect by SSH on this machine but only to do this or that task"). To make a restricted access, you must set the user shell (at the Unix level) to a specific executable which does the filtering job, such as rssh, but I do not find this to be a really robust solution.