This is almost certainly someone's attempt to workaround some of the NAT issues you can experience with SIP - I suspect they've set it up so that when an outbound SIP connection is made outbound, *all* connections to port 5060 are NAT'd back to the host that made the connection so if a reply comes from a different address (which is allowed in the SIP standard) it still gets through, probably combined with an ALG that is translating internal IPs in the SIP message into the external one. Normally you'd expect your NAT device to just accept packets from IPs you'd connected out to (the service provider in this case).
If it's a phone connecting out that's not a big problem, as most phones these days can be (and should be) configured to ignore traffic that's not from the configured server / proxy, and even in the worst case all that happens is they ring - they're not going to end up placing an outbound call.
I can understand smaller installers not thinking to put brute force protection on a PBX that they are not intending to expose to the internet - unless you've seen issues like this and had to deal with the crazyness of ALGs etc you wouldn't expect it.
Frustratingly all these sorts of things (ALGs in particular) actually normally make VoIP less likely to work - any competent ITSP will have a Session Border Controller (SBC), or something carrying out the same functions, at their end, which will just handle the NAT issues (i.e. all signalling will come back from the same IP and where necessary they will proxy the audio etc). However, with an ALG, 9 times out of 10 (at least in my experience) it has 'modified' the SIP messages in such a crazy way that the SBC can't work out what to do, and so you get one way audio or calls cutting off after a short time etc...