Das ist nun wirklich eine Nuance an Inkonsistenz, die Sie hier ansprechen. Und außerdem denke ich, dass dieser Umstand leicht zu erklären ist.

Meine Vermutung:
1) Die Nummerierung der Geräte, die in FreeBSD über den Treiber ada(4) angesprochen werden, resultiert aus dem darunterliegenden Subsystem namens CAM(4), welches typisch für Unix & C bei 0 (in Worten: Null) zu zählen beginnt.
Letzteres kann mittels sogenannter hints sogar so konfiguriert werden, dass die Zuordnung zwischen Gerätetreiber(-instanz) (bzw. deren Nummer) und CAM-Bus-Nummer (plus optional LUN sowie target-Nummer) beliebig geändert werden kann, siehe die oben referenzierte "Handbuchseite" . Leider kann man keine Art Schema oder dergleichen angeben. Eine solche Zuordnungsänderung ist fix und müsste nach einem Hardwarewechsel ggf. angepasst/ergänzt werden.

Bereits vor CAM, welches erstmals mit FreeBSD 3.0 (1998) erschien, muss es auch eine Implementierung eines Nummerierungsschemas gegeben haben. Soweit ich weiß, begann/beginnt jede Nummerierung der Instanzen eines Gerätetreibers in FreeBSD (unixtypisch?) bei 0 (in Worten: Null).

2) Die Nummerierung der Partitionen gemäß GPT resultiert aus dem spezifizierenden UEFI-Standard. Danach wird die Zählung der (GPT-)Partitionen bei 1 (in Worten: Eins) begonnen.
Das UEFI-Forum mit Intel, AMD, Microsoft und HP entstand 2005; 2006 erschien EFI 2.0, siehe hier. Intel Itanium lief seit Anbeginn (2001) mit EFI, Apple nutzte EFI auf Intel-Systemen seit 2006 und erste Mainboards für Endanwender mit EFI brachte ASUS erst Ende 2010 auf den Markt, siehe hier.

3) FreeBSD wird einen Teufel tun, den UEFI-Standard aus diesem Grund (Inkonsistenz zur Nummerierung der Geräte) zu verletzen - erst recht nicht im Nachhinein (aus Kompatibilitätsgründen).

Ergo: Dieser Umstand ist historisch gewachsen, und - mit Verlaub - ich finde, dass man das nicht FreeBSD anlasten kann; eher noch dem UEFI-Forum bzw. dessen Vorläufern.