Alignment is required for page tables because there's literally nowhere to store the low address bits.
The bottom 12 bits of a page directory entry is flags like present, accessed, user/supervisor, whether this is actually a largepage instead of a pointer to a page table, etc. https://wiki.osdev.org/Paging#64-Bit_Paging. Similar for the higher 2 levels of tables; see Why in x86-64 the virtual address are 4 bits shorter than physical (48 bits vs. 52 long)? for official names for different levels, and a nice diagram of how x86-64 4-level page tables work.
In theory the top-level page table pointer (set with mov cr3, rax or whatever) does have a full 64 bits, but the low 12 bits are ignored / reserved. Or with a control-register setting, repurposed as process-context ID (PCID) to tag non-global TLB entries so they can survive across CR3 updates, making frequent context switches somewhat less bad.
There'd be very little reason to want a misaligned page table, and it does simplify the HW: the physical address can just concatenate some bits together instead of adding with possible carry into the page-number bits. And since virt->phys mappings happen in aligned 4k blocks, free physical memory in aligned 4k blocks is what you want to track anyway.
(And with paging enabled, load/store instructions the kernel executes in functions that read and/or update page tables can only use virtual addresses. An aligned 4k of phys memory can be addressed through one virtual 4k page, instead of maybe costing the kernel multiple TLB misses when accessing 4kiB split across two virtual pages. Many kernels such as Linux will direct-map all of physical RAM, or large chunks of it, with 1G hugepages, but still...)
Actual physical pages (page frames) should always be aligned, so the offset-within-page virtual address bits are also the physical offset-from-4k-boundary address bits. Among other things, that lets an L1d cache have the speed of VIPT (indexing based on bits from the virt addr) without any aliasing problems if the cache is small enough and associative enough. The bits below the page offset effectively translate for free, without the TLB, so such a VIPT cache is effectively PIPT.
It also means two virtual pages can't partially overlap; they either map to the same physical page or not. (Not counting largepage / hugepage). And it would make each TLB entry larger, which is a Bad Thing. e.g. on an early x86-64 with 40-bit physical addresses, a 4k page's TLB entry only needs 28 bits of physical address, instead of 37 if we had only 8-byte alignment.
So that means an actual PTE shouldn't waste space on low address bits. Having a page directory entry use an identical format makes a ton of sense.
There are actually 11 unused high bits above the highest reserved bit (#52) in a PTE/PDE, so there actually is room if we didn't care about leaving more unused space for OSes to keep bookkeeping data. (They're fully ignore by HW.) So the HW page table design could have left only 3 physical bits implicitly zero (8-byte alignment), while still allowing up to 52-bit physical addresses, if anyone had thought that was worth doing.
Either by left-shifting the phys address field, or keeping flags at the top. Low bits are more efficient for software to manipulate on x86-64. But there's no good reason to make HW throw those bits around at all.
PAE and thus x86-64 use the same flag-bit layout at the bottom of each entry as 32-bit legacy page-tables (4 bytes per PTE, 2x 10-bit levels mapping 32-bit virt -> 32-bit phys which only had 3 unused PTE bits, in bits [11:9]).
One of AMD's major goals was to reduce barriers to entry, making porting of OSes and toolchains easier, to increase the chance of getting traction and not becoming dead weight in their CPUs. Also keeping HW as similar as possible so they could share transistors in decoders and so on, which meant not fixing many x86 warts. Fortunately Intel's PAE format is very reasonable, so they could literally use it directly, just adding 2 more levels.
