The DHCP server hands out its own IPv4 address in the router option by default, also in this scenario I guess. This adds an unnecessary addition hop on a dumb AP unless you override it by configuring the Pi in a custom router option.
I don't think there is a "blanket" recommendation for such thing. In a scenario where you have a decent router but a low specs AP, or where you, for example, set static leases on the DHCP Server and want all config to be on one device (i.e. the router), then that could be a valid recommendation.
But there is more to that. In fact, if I were you, I world probably make the DHCP Server on the AP if most of your devices (or the important ones) are connected to it. That way, if you happen to turn the Pi off for a reason or another, you still have IPs and a functional local network.
Especially for IPv6 you really want to run the DHCPv6 server (odhcpd) on the router, and not a random station (such as an AP) in your network. This is particularly important for dynamic (as-in changing) IPv6 prefixes, as prefix changes need to be communicated quickly (so odhcpd really needs to be able to notice link changes of the WAN interface), for IPv4 this is less of an issue, given that the gateway does NAT and abstracts globally routable IP space from the internal clients (they only have to deal with static RFC1918 IPs).