x64では32ビット整数と64ビット整数の演算はどちらが高速？ のページで

Sayuriさんの回答のコメントでEgtraさんが

x86/x86-64‌の32/64ビットモードでは、16ビット‌演算も、やはり32ビット命令より1バイト‌多く必要になります（オペランドサイズプリ‌フィックス）。

とコメントしていたのですが、
オペランドプリフィクスというのを知らなかったので調べた所、
このようなページが出てきました。

このページの下部の方に

ここで気が付くのは、同じ命令でも、違うコードが出ている。
例えば、 mov (%esi), %eax は

16bitでは、67668B06
32bitでは、8B06
64bitでは、678B06 となっている。

67というのは、アドレスサイズプレフィックス 66というのは、オペランドサイズプレフィックス

(省略)

16bitモードでは、アドレスサイズ、オペランドサイズが16bitが基本。 67を付けるとアドレスサイズが32bitになる。
66を付けるとオペランドサイズが32bitになる。

32bitモードでは、アドレスサイズ、オペランドサイズが32bitが基本。 67を付けるとアドレスサイズが16bitになる。
66を付けるとオペランドサイズが16bitになる。

64bitモードでは、アドレスサイズ64bit、オペランドサイズ32bitが基本。 67を付けるとアドレスサイズが16bitになる。
66を付けるとオペランドサイズが16bitになる。 48を付けるとオペランドサイズが64bitになる。

と書いてあり、ここでようやく1バイト増えるの意味が分かり、

「なるほど。64bitのプロセッサーでは16bit演算や64bit演算をする場合には、
同じ命令でも66や48などのプリフィクスを付けるため、命令自体のサイズが1バイト増え、非効率になると言っていたのか」

となんとなく納得したのは良いものの、
そもそものオペランドサイズ、アドレスサイズというのが私の理解で合っているのか分かりません。
(そもそも上の鍵括弧内もあっているか怪しいですが)

オペランドサイズはそのまま「被演算子となるデータ型のサイズ」の事をオペランドサイズと呼んでいるという事で良いのでしょうか？

もし、そうであるならば、16ビットモードの時代は、2**32以上の符号無し整数を扱う方法は無かったのでしょうか？

また、64ビットモードの場合などで、わざわざ命令のサイズを増やしてまで、
オペランドサイズを16bitにする意味はあるのでしょうか？

それとも、命令のサイズを増やしても演算スピードが速くなる事はあるのですか？
わざわざshort、byteを使う場面というのはあるのですか？

アドレスサイズは、割り当てられるアドレスの数で、例えば32ビットOSならば、2**32しかアドレスを割り振れないから、
4GBまでしかメモリを認識しなかった。

この理解であっているのでしょうか？

この理解であっている場合、64ビットOSでは2**64のアドレスを扱う事ができるはずですが、
実際にはOSごとに扱えるメモリサイズは限られていると思います。

この場合、2**64で振られるアドレスの内、上位のビットはアドレスとして使わないという事になるのでしょうか？
それとも、OSごとにアドレスサイズを変えているのでしょうか？
(それだと、上の話のアドレスサイズ64bitが基本というのと合わない気がするので、これは多分違うとは思っている)

また、これもオペランドサイズの時と同じ質問ですが、
わざわざ命令のサイズを大きくしてまで、アドレスサイズを16bitに縮小する意味があるのでしょうか？

それとも、命令のサイズを増やしても演算スピードが速くなる事はあるのですか？