Meterpreter is a multi-stage payload where the first stage is send first which then downloads the second stage DLL. Two things you need to understand here: what transport will be used by the Meterpreter to communicate with the handler and whether the first stage should connect back to the handler or the handler should connect to the listening socket (reverse vs bind).
There are three types of transports available: TCP, HTTP and HTTPS. If you are operating inside a LAN environment, you can use the TCP transport since it is a reliable transport mechanism. However, TCP transport needs an established socket to communicate which means if for some reason the session gets close between the attacker's machine and victim's, it can't get reconnected (unless persistence is already achieved). TCP transport can't traverse proxy servers in order to access Internet and first stage transport is in plain text which can trigger IDS/IPS.
HTTP and HTTPS both use WinInet which means if the victim is behind an HTTP proxy, the first stage meterpreter will be able to use the proxy server and the cached credentials (if required) to traverse the proxy and access the Internet.
HTTPS transport has the added benefit to transfer the second stage DLL on a complete SSL tunneled transport that can't be sniffed by IDS/IPS unless the session is MITM-ed at the proxy.
In case of bind vs reverse, reverse is almost always the preferred method because a lot of times organizations have script ingress filtering in place but egress filtering is not that much strict (although it is changing).
One final thing you need to understand is that compared to TCP, HTTP(S) transport is bigger in size that is why it won't be fit in every exploit due to the limited payload space they can carry. However, egy7t did some great work to reduce the size of reverse HTTPS transport so that most of the exploits can carry it. You can find more details regarding this at Shellcode Golf: Every Byte is Sacred.