Hub VNET in cloud-only environment approach

I was told recently that the Hub VNET is only used in case there is on-premise networking to/from considerations.

I am quite surprised as were many, at the table.

I was under the impression if I have, say, a AZURE Cloud only env. that I could still have a Hub Spoke approach. Or is this not so? What would be the preferred non-Hub Spoke approach if there is peering or inter-VNET access required?

I am aware of VNET Peering and other methods to access resources in other VNETs, API's and Private Link.

The hub-spoke approach works great in some scenarios in cloud-only environments - although in most of docs or architectural patterns Microsoft shows it together with on-prem connectivity.

I used it frequently when we shared some resources like ACR, Log Analytics or simply to host a jump host (with Bastion) to access resources in other networks.

One of the most common scenarios is also the Azure Monitor Private Link Scope, where the hub-spoke topology is recommended:
https://learn.microsoft.com/en-us/azure/azure-monitor/logs/private-link-design#hub-and-spoke-networks

In an Azure Cloud only environment, you can still have a Hub-Spoke approach and this is the recommended one.

While you can cross-peer different spokes to form a Mesh for spokes to exchange data (in a non-Hub scenario), this will become complicated as the number of spokes increases. You will have to configure 1:n Peering in every VNet.

With Hub-Spoke model, you have to route spoke-spoke traffic via Hub Vnet, but the advantage here is that the Hub Vnet becomes the single point entry for the environment and you can deploy resources here that would be shared and used by all other VNets (such as custom DNS server, Firewall)