A few comments for the "look forward to having that all explained to me" part.

As already identified the message is from parted as a warning, not something like mdadm/lvm/dm that actually detect a real issue (yet).

At the core of the check it does:
ok = (part->geom.start % pa->grain_size == pa->offset);
Attributes of "part" are our configuration and "pa" are disk attributes it derives disk attributes.

Parted defines:
ped_device_get_minimum_alignment
ped_device_get_optimum_alignment
The values it considers are from  /sys/block/<disk>/queue/

The workaround of "1 compact" works because compact it is defined as:
"This is a special unit that defaults to megabytes for input, and picks a unit that gives a compact human readable representation for output."
That means "1 compact" translates into "1 MB" which is a good alignment for the usual values of 4k or so.
In fact >=1M is parteds default expected value for "good" alignment if it has no further disk information.


I can reproduce and test the behaviour with almost any current block testcase we have. in curtin vmtests
In there curtin just does what it is told - no magic to avoid alignment issues there.
So the following yaml translates to the latter commands:
      - id: sda
        type: disk
        ptable: msdos
        model: QEMU HARDDISK
        path: /dev/vdb
        name: main_disk
      - id: sda1
        type: partition
        size: 3GB
        device: sda
        flag: boot
      - id: sda_extended
        type: partition
        size: 5G
        flag: extended
        device: sda
      - id: sda2
        type: partition
        size: 2G
        flag: logical
        device: sda
      - id: sda3
        type: partition
        size: 2G
        flag: logical
        device: sda


Running command ['parted', '/dev/vdb', '--script', 'mklabel', 'msdos'] with allowed return codes [0] (shell=False, capture=False)
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'primary', '2048s', '6293504s'] with allowed return codes [0] (shell=False, capture=False)
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'extended', '6293506s', '16779266s'] with allowed return codes [0] (shell=False, capture=False)
Warning: The resulting partition is not properly aligned for best performance.
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'logical', '6293509s', '10487813s'] with allowed return codes [0] (shell=False, capture=False)
Warning: The resulting partition is not properly aligned for best performance.
Running command ['parted', '/dev/vdb', '--script', 'mkpart', 'logical', '10487815s', '14682119s'] with allowed return codes [0] (shell=False, capture=False)
Warning: The resulting partition is not properly aligned for best performance.


Curtin starts the first partition at 1 MB and ends at 1MB+Size
In our example we requested 3GB
START of 1st Partition = 2048
END => 2048+((2**30)*3/512)
So the partition goes 2048s to 6293504s
Note  ((6293504-2048)*512)/(2**30) = 3GB


If the config is rather vague like in the example above we might try to auto-align in curtin at the cost of some space.

As soon as the yaml from maas will contain sector specifications curtin has to obey these orders.
Also as Blake pointed out MAAS could "overalign" at e.g. 4MB to always be on the safe side - and if MAAS specifies sectors is the only way.