But a 2 digit date should take less than 7 bits. Were they using systems that didn't use 8 bit bytes? Why wouldn't the dates work from, say 1900 to 2155?
Even if a system internally can store a timestamp with nanosecond precision since the beginning of the universe, all that precision is lost when communicating with another system if it must send the timestamp as a six character string formated as "yymmdd" in ASCII.
Sure, they could have used a custom encoding. But that increases maintenance cost and extra development work. All to solve a problem that nobody cared about at the time.
You are assuming 8 bits per byte, but a byte can be any number of bits.
With two bytes of 7 bits each, the range is only about 40 years. Is is also impractical when the storing media is punch-cards, and the systems adder unit only counts in binary coded decimal.
It means that data interchange is now much more complicated too. How do you get everybody to agree on the same 2-byte representation for dates? This is the 1960s, so you can't just email them. You have to have somebody type up a letter and mail it. Or if you want to get on the phone, a 3-minute international call will cost $12, which is about $100 in 2017 dollars.
Plus then you can't look at a hex dump or a punch card or front panel lights and see the date, so now you've made debugging much harder.
But it's worse than that. In the 90s a lot of code used 16-bit values, character strings. That is, it stored a char(2), parsed it as 2-digit number and then converted it to a date by adding 1900.
So it was only really "saving space" when compared with storing a char(4).
No punch cards or BCD, I'm talking about DOS/Windows systems.
Some systems, where storing numbers in columns of characters were common practice (COBOL idiomatic style?) stored the date as two digits (possibly BCD), so the possible range is 00-99 no matter how many bits are used.