Assuming you handle the changing between language versions (as in the example of your first bullet point - sending a page) in a reasonable manner, then yes, you should consider having the language in your URL, but for a reason you've not mentioned here.
Note: This generally gets referred to as 'language/region' because, more often, the two letter codes are used to define both a language and a region e.g. en-us, en-uk, es-mx, es-es
The Benefit of Domain Authority
Assuming the growth and prosperity of your domain is a goal, then having all your content in subdirectories under your root domain is the best way to quickly develop domain authority and consequently to rank well in search engines.
Note: Domain Authority is gained when other sites link to yours. Generally speaking, the more links a domain (or page) has pointing to it, the more "authoritative" it is, and the more likely it is to rank for a given keyword. (This is why wikipedia does so well in search)
Your other options i.e. separate CCTLDS (.com, .ca, .co.uk) and subdomains (us.site.com, ca.site.com) both create silos for authority. That is, links to any one site or subdomain don't benefit others.
If all your content is one domain, links to anywhere benefit everywhere.
(I've started to refer to this as 'The Microsoft Model', just because it's a high profile site that uses this method, and when I'm explaining it, I can just link to http://www.microsoft.com/ There are lots of big international brands that use this method. The other 'biggest international brand' I could find quickly is http://www.nike.com/)
Be sure to use hreflang
hreflang
is a method of distinguishing between your language/region variations and is a way of telling (specifically) Google, "you are going to find other versions of this page that are very similar, but with language or other content differences. This version of this page is for english speakers in the United States."
https://support.google.com/webmasters/answer/189077?hl=en
Switching Between Languages
A best practice for how to handle this has yet to emerge, and there's a lot of variety in how this gets handled. How you implement is up to you.
Visitors to the Root
Some sites show visitors to the root i.e. 'site.com' a list of options (often just lists of text links because it's very easy to get the map/country/flag/language thing wrong) but more often these days, the users' region is detected and they are taken directly to the appropriate language/region. i.e. a link to site.com goes to site.com/en-us
Visitors to Deep Pages
You gave the example of sending a link to friend. What if you link to site.com/en-us/ux/ but he's in France?
You have a couple of options. (assuming a French version of the page exists. If not, the user goes to the linked location)
1) Simply show the user the french version of the page. In a lot of cases this will be preferable for everyone.
2) Show the user the English version of the page, but detect that they are in France, and show them an unobtrusive notice on the page (in French) that tells them there's a French version and asks if they'd prefer to see that.
You should of course make sure it's always possible and easy to switch languages, and that you keep users in the right content areas once they've been 'located' (you'd use cookies to do this, but it sounds like you've got a handle on that part)
site.com/en
, I'd just go withsite.com?lang=en
. This way you would use basically the same webpages and everything (the same files, directories, and code); you would just use json files or something to read separate translation data, but everything else would be the same.site.com/en
can easily translate tosite.com?lang=en
on the server side. Otherwise, you end up doing something like:site.com/path/to/content?lang=en
and that's ... yuck ...Accept-Language
, in my opinion is the only valid start point for multilingual websites, everything else is a set of questionable tactics and half-solutions that has been filling the gap since the dot-com bubble when the gold rush on the Web was led by cowboy developers who "learned" HTTP by word of mouth along a long string of "oral transmission" from other developers who may or may not have known whatAccept-Language
even was. I am sorry but there isn't a single great answer to this question among those listed as I write this. They're pragmatic, but "defective by design".