The 16 KiB (as $2^{14}$B is obviously 16 KiB) record size limitation has been true for every TLS specification starting from TLS 1.0, the first one that was not developed by Netscape who developed the SSL versions up to 3.0. Note that message compression (up to TLS 1.2) and encryption may increase the size beyond 16 KiB - how much depends on the TLS version.
Up till now I have seen this explained as a practical buffering limitation. You can / should only start decryption / decompression after the whole record has been received, and for that you need to allocate a buffer. Not all devices support a larger buffer size, and the overhead introduced by the record layer is already insignificant compared to the data contained in the records.
Note that the data in a record should definitely not use 64 kiB as that's the default size of the TCP window. The encrypted record would become larger than this window, and that would require a larger buffer size on e.g. embedded devices. On the other hand, it should not be too small or the handshake messages would not fit anymore (due to the included certificate chains, mainly).
Just to provide some backing for my claim, here is a text in RFC 8449: Record Size Limit Extension for TLS
Receiving large protected records can be particularly difficult for a device with limited operating memory. TLS versions 1.2 [RFC5246] and earlier permit senders to generate records 16384 octets in size, plus any expansion from compression and protection up to 2048 octets (though typically this expansion is only 16 octets). TLS 1.3 reduces the allowance for expansion to 256 octets. Allocating up to 18K of memory for ciphertext is beyond the capacity of some implementations.
Note that this RFC allows users to limit the record size even further, it does not allow implementations to grow the record size beyond what is allowed.
And now for some history, the SSL 0.2 specifications:
Where byte[0] represents the first byte received and byte[1] the second byte received. When the 3 byte header is used, the record length is computed as follows (using a "C"-like notation):
RECORD-LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1];
IS-ESCAPE = (byte[0] & 0x40) != 0;
PADDING = byte[2];
which leads to:
For a two byte header, the maximum record length is 32767 bytes. For the three byte header, the maximum record length is 16383 bytes. The SSL Handshake Protocol messages are constrained to fit in a single SSL Record Protocol record. Application protocol messages are allowed to consume multiple SSL Record Protocol record's.
So it seams that subsequent protocol specifications decided to use the smaller record length (excluding overhead).
Disclaimer: K means Kelvin, k means kilo - which literally translates as thousand in old Greek - and Ki means Kibi, the binary (almost) equivalent meaning 1024. b means bits and B means bytes. Thus 1 KiB is 1024 bytes. Bytes and octets are the same thing nowadays.
