The most common MitM vectors are any kind of shared network. This can range from using your neighbor's WiFi (here they, or at least their router, are automatically in a MitM position), to leaving your WiFi open (enables an attacker to connect and do ARP spoofing), to using public networks at coffee shops, airports, hotels, schools, etc. (the owner has automatic MitM; others on the network can use ARP spoofing), to business/workplace networks (your admin has MitM, others may or may not be able to gain it).
Accidentally connecting to malicious networks is also a risk. It's very easy to set up a "fake" access point (using a PC) that has an arbitrary SSID and password; if your laptop/tablet/phone is set to automatically connect to a known network, and the attacker can spoof that network (like, maybe it's the one at your favorite coffee shop, even though you're not there right now), then the attacker can use that to get a MitM position when your device connects automatically. Most people let their devices connect automatically to any network they've seen before (and some even connect to popular networks that they haven't seen before), which puts them at risk from such attacks.
HOWEVER, all the threats mentioned so far are pretty minimal as long as HSTS is used (or the app avoids ever using insecure HTTP). There are still some risks. For example, Heartbleed could be used against clients even if the server was patched, assuming the attacker had a MitM position, and some TLS clients are still vulnerable to it because people are bad at pushing updates to old software. In general, though, it's hard to effectively attack somebody this way.
Finally, though, there's the risk of interference at the ISP or backbone level. Many countries restrict the Internet within their borders, and in some cases this is done via a MitM position. Such threats are among the most dangerous, as a nation-state (especially) can simply procure fraudulent certificates that almost any device will trust, enabling interception of TLS traffic (unless good cert pinning is used).
Even without that, though, it's not that rare for CAs to issue TLS certificates to untrusted entities. It's not common, but it happens. Additionally, attacks (such as arbitrary file reads) against web servers can be used to steal their TLS private keys, enabling attackers to successfully spoof those servers. Based on my experience, that's a pretty common class of vulnerability. Such stolen certificates will not only get past HSTS, they'll also pass certificate pinning. There is no perfect defense.
