I don't think I understand you.

1 word is 8 bytes, and if you use two columns, the first one having size 2 bytes, and the second – 8 bytes, you'll end up spending 8 + 8 = 16 bytes, because the first one (2byte in length) will be aligned with 6 zeroes to fill the whole "8-byte word". For example, with smalling (which has size 2 bytes but might be aligned, depending on the "column tetris" situation we have) + int8:

  test=# select pg_column_size(1::int2);
   pg_column_size
  ----------------
                4
  (1 row)

  test=# create table tttt1 as select 1::int2 as c1, 2::int8 as c2;
  SELECT 1
  test=# create extension pageinspect;
  CREATE EXTENSION
  test=# select lp_len from heap_page_items(get_raw_page('tttt1', 0));
   lp_len
  --------
       40
  (1 row)

-- the total length of the tuple in this example is 40 bytes. Why 40? Because the tuple header is 23 bytes aligned to 3 "words", hence 24 bytes – so total is 24 + 8 + 8 = 40; though, effective data size us just 23 + 2 + 8 = 33; and 7 bytes are "wasted". And our int2 column was aligned by 6 additional bytes, to whole 8-byte word.

Of course, if the second column is of size 4, then both columns fit into a single word – let's try real + int4:

if we'd have 2 int2 columns, followed by a int4 one, we'd use just one word (8 bytes to store this data, plus 24 bytes for tuple header):

  test=# create table tttt2 as select 1::int2, 2::int2, 3::int4;
  SELECT 1
  test=# select lp_len from heap_page_items(get_raw_page('tttt2', 0));
   lp_len
  --------
       32
  (1 row)

-- in this case, the tuple length now is 32 bytes (24 bytes tuple header + 8 bytes for the data). Alignment was not needed.

Thus, I don't see what's wrong with the document – probably I just didn't understand you.

An update in postgres will always copy the tuple for MVCC, so it can't take advantage of an optimization like this to modify it in place.