Nope. They don't include leap seconds.

The technical definition is "Number of days since 1st Jan 1970 in GMT" × 86400 + "Number of seconds since midnight GMT"

Unix time clocks does funny things when there's a leap second which is about 1½ years. Some pause for a second, some go forward then backward etc.

Attaching a timezone to a time is an information in itself. By coercing time data to UTC you are losing this bit of information.

A user may want to have some information shown as 8AM PST at the same time he wants another one shown as 8AM CET.

A timestamp and a timestamp with time zone are two different things and you need to use the appropriate one (which is usually time zone with timestamp). However, the argument is really not about attaching timezone information to timestamp which is an unfortunate but necessary thing, but storing times in the archaic multiple-base mixed format stuff humans traditionally use (because it's human-friendly) that computers simply do not need. An ISO timestamp mixes bases 60, 24, 12, a weird mix of base 28, 29, 30 an 31, and a weird mix of 365 & 366. This is craziness.

You mean UTC? GMT is tied to London, and could be confused with BST during summertime. UTC isn't.

Yes.

Technically UTC = GMT and always has and for this "epoch time" conversation is completely identical.

However there's a people problem. Some people think "GMT = the time in London now" which it isn't, since the UK switches to BST for daylights saving. Saying "UTC" avoids the "time in London" interpretation problem.