I find it difficult to understand this too. In most cases Asterisk only needs one definition, which for chan_sip should normally be a peer. I think there is even less need for chan_pjsip. Although I’m only answering from an Asterisk point of view, I think I’ve seen reports of people using only one definition for FreePBX, so I don’t think this is a FreePBX thing, even though the structure of the GUI hints that you need the inbound definition.
There are cases where, for example, there might be multiple source addresses that don’t match the URL needed for outgoing calls, but there you would probably need multiple inbound entries (and chan_pjsip can handle these with multiple match lines in an identify section).
I’m not certain of the original reason for incoming sections, but it is very clear that ITSPs provide sample configurations that are not properly researched. I think they often copy another provider’s configuration and fail to remove features they don’t need, as well.
They tend to use obsolete names for options and to enable unnecessary workarounds. They can also use options that are only relevant to the other section.
Having two can actually be risky, as I don’t think Asterisk formally defines which section, for the same host address, will match the provider’s IP address. I think a lot of them rely on undocumented behaviour.
Although you shouldn’t be starting with chan_sip nowadays, my advice would be to start from first principles, and ignore the provider’s suggestion, and try to use a type=peer outgoing section as the only definition of the trunk. Although you are less likely to get provider supplied chan_pjsip configurations, I have seen an example here of what looks like a bad, literal, translation of chan_sip one, and many people mechanically translate from poor quality chan_sip definitions, so I’d also say try to start from first principles for chan_pjsip and ignore provider ones and translations of chan_sip ones.
Generally when people define inbound sections a type=friend, it just opens a minor security hole, as the section name is not something that the provider sends, so there can never be a user match (type=friend, really a combination of type=peer and type=user, with the type=user match being preferred). The security hole is small because you shouldn’t allow incoming calls from your provider to initiate arbitrary toll calls.