Length of varchar column - is there an advantage to using 255? I often come across columns that are varchar(255), so presumably this is a convention of sorts. 255 is 2^8 - 1. So is there something 'magical' about lengths that are 2^n - 1? Or just specifically 255? Is there a performance or storage optimisation advantage to certain specific varchar lengths? Or is this just old wisdom which is no longer applicable to current versions of MariaDB and MySQL?
I rant against 255 occasionally.  Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.
In MySQL, there are reasons to stop at 191, 255, 767, 3071, 64K, and probably other values.  Some depend on Engine, some on CHARACTER SET, etc.
A VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified.  However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size.  That is, this is not a valid excuse for using 255.
Use a length that is

Big enough to conservatively never be exceeded, yet
As small as seems reasonable.

While I am ranting...  CHAR (fixed length) is rarely advised.  And almost always it should be CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc.  (MD5 and UUID should be taken a step further, but that is another rant.)
Potential negative impacts of blindly using '255':

If you have a lot of columns, you could hit a max row size limit and CREATE TABLE will fail.
You could overflow a limit on index size.
Complex SELECTs may need a temp table, and may use MEMORY for it.  In this case, VARCHAR(255) becomes CHAR(255) for the temp table.  And, if using utf8, that is 755 bytes for every row!  (8.0 fixes this design flaw?)

Related:  Don't blindly use BIGINT for all numbers.  It takes 8 bytes.  Even INT is overkill, at 4 bytes.  See MEDIUMINT, SMALLINT, and TINYINT.  Be aware that the (2) on INT(2) means nothing; it still takes 4 bytes.