You need insecure=invite when the the peer will either never try to authenticate to you on an invite, or will try to authenticate to you using a secret which differs from the value of your secret setting. This typically happens with ITSPs who generally never try to authenticate. remotesecret makes this usage largely redundant, because you will never request authentication if you don’t have secret set and remotesecret covers the case where you need to supply authentication.
insecure=port means that you will accept invites from a different port number than the the one you got from the registration, or the one that you configured to statically send to. That might happen because of NAT, or because of the use of proxies. However, as with anything that reduces security, you should demonstrate a real need before using it.
Most of the cookbook uses of insecure seem to arise from ITSPs. Before remotesecret, they typically needed insecure=invite, but probably thought there was less likelihood of customer dissatisfaction if they made the customer as insecure as possible, so used very. I think the name, very, was coined to warn against excessive use, but failed in this. I think that requiring port,invite was then done to make people think about what they really needed, but, instead, people just translated very into port,invite, without thinking.