Using column size much larger than necessary

SQL Server uses column lengths when allocating memory for query processing. So, yes, in short, you should always size columns appropriately for the data.

Memory allocations are based on the number of rows returned by the query multiplied by half the declared length of the column.

Having said that, in this case where you've got 6 rows you probably don't want to over optimize prematurely. Unless you JOIN this table to another with millions of rows, there won't be a massive difference between a varchar(24) and a varchar(32), or even a varchar(128).

Your second question asks about aligning column lengths on binary multiples. That's not required at all since SQL Server stores all data in 8KB pages, regardless of the length of each column.

With 6 rows, no, there will be no observable benefit. That entire table will fit on a single page so lowering the maximum potential space you’ll use on that page while still occupying that entire page is really no different in all practical sense.

On larger tables, though, right-sizing is crucial. The reason is that memory estimates will be based on the assumption that every value will be 50% populated. So if you have varchar(128), every value will expect to occupy 64 bytes, regardless of the actual data, therefore memory grants will be 64b * number of rows. If all the values will be 32 characters or less, making it a varchar(64) or even varchar(32) is probably a better choice. If a large percentage of values are close to or at the cap, you could even argue for char to take volatility out of it.

As for benefits of having string lengths capped at powers of 2, I don’t think on today’s hardware anyone could demonstrate any obvious advantages.