Pay-to-PubKey (P2PK) and pay-to-PubKey-Hash (P2PKH) were both introduced in the original Bitcoin 0.1 release. P2PK was used by default for mining and payments received using the interactive IP-to-IP payment protocol; P2PKH was intended for use in non-interactive payments---but P2PKH transactions take up more space in the blockchain than P2PK.
Is this space savings why Nakamoto chose to use P2PK for mining and interactive payments even when he had P2PKH available, or did he have some other reason for using different transaction types? I think only he knows.
In a situation where you don't need the shorter P2PKH addresses, such as mining, interactive payments, or paying to your own pubkey for change, using a P2PK may be the better option, although there is a security advantage to P2PKH if you don't reuse addresses and if ECDSA someday gets broken in a certain way that makes attacks possible but slow to execute.
Type Output Input Total Bytes
ScriptPubKey ScriptSig
push ....... 1 push ... 1
<key> ...... 33 <sig> ... ~72
P2PK checksig ... 1
-------------- -------------
Total ...... 35 Total ... ~73 ~108
dup ........ 1 push .... 1
hash160 .... 1 <sig> ... ~72
push ....... 1 push .... 1
P2PKH <hash> ..... 20 <key> ... 33
equal ...... 1
checksig ... 1
-------------- --------------
Total ...... 25 Total ... ~107 ~132
The numbers above assume that you're using a compressed public key, which are widely used today but were not implemented until Bitcoin Core 0.6.0. If you want to consider the older "uncompressed" public keys, add 32 bytes to the <key>
byte sizes. Also, we ignore all constant factors in creating an output or input and just consider the number of bytes in the script.
I'm not aware of any compatibility issues---plenty of miners and mining pools use their own software to pay to P2PKH addresses, as you can see from the coinbases in recent blocks.