An actual FID or OID field is not a numeric field. It is a special data type known as Object ID. See the help files
If you run some tool that outputs a table with an attribute field based on the FID, for instance Near, that field is of data type LONG.
If you perform a Summary Statistics on the actual FID field, the data is treated as a numeric type by the tool. If you attempt the same from the attribute table, it's treated as a string (hence the First and Last options, but none of the numeric). Actually, that's a somewhat faulty statement - it's more like a string. Since the FID is unique, you can get either the first or last value associated with each value in the field you're summarizing on. But math operations on such unique id values are meaningless, just like they would be for any text string values. So even though you can do it in Summary Statistics, the result doesn't mean anything. In much the same way Zip Codes aren't numbers, neither are FIDs even if they're represented by numeric characters.
I don't know for sure how it treats it with a join operation, but I believe it must be numeric based on the joins that are successful (doubt you can join based on the FID field to a string field even if the strings are matching numbers).
Depending on where you look at it, the OID can be converted to different data types (see last link) but within ArcGIS it is its own animal.
More info (including differences between OID and FID, including renumbering):
http://support.esri.com/de/knowledgebase/techarticles/detail/37480
http://resources.arcgis.com/en/help/main/10.1/index.html#//019v00000002000000
So to summarize that big paragraph up there and answer why you can't run statistics on the FID field itself from the table is because those statistics are meaningless:
- Count = number of records or that -1
- Min = 0 or 1
- Max = number of records or that -1
- Sum is 1+2+3+4+5+6... + number of records or that -1
and so forth. Null might be useful, except in order to be an FID/OID the value cannot be Null, so that statistic would always be 0. Only your First/Last statistic, which can be accessed from either place, serves any purpose as you demonstrate in your example. But (and here I had an ah_HA! moment) you're right, that causes an error. The only explanation I can offer is that the attribute table Summarize and Summary Statistics are two different tools (hence you can use CASE with one but not the other) and must handle the Object ID data type in different ways. Technically, it shouldn't work in Summary Statistics (and even throws an error warning when you first set it, but does it anyway).
Similarly you cannot Summarize on the FID field because every value in FID is unique - hence the summary table will look exactly the same as the attribute table.
