Comment 1 for bug 1614345

It's not quite absent, it was never fully implemented and it's also feature flagged:

$ JUJU_DEV_FEATURE_FLAGS=post-net-cli-mvp juju help create-subnet
Usage: juju create-subnet [options] <CIDR> <space> <zone1> [<zone2> <zone3> ...] [--public|--private]

Summary:
create a new subnet

Options:
-m, --model (= "")
    Model to operate in. Accepts [<controller name>:]<model name>
--private (= true)
    disable public access with shadow addresses
--public (= false)
    enable public access with shadow addresses

Details:
Creates a new subnet with a given CIDR, associated with an existing Juju
network space, and attached to one or more availablility zones. Desired
access for the subnet can be specified using the mutually exclusive flags
--private and --public.

When --private is specified (or no flags are given, as this is the default),
the created subnet will not allow access from outside the model and
the available address range is only cloud-local.

When --public is specified, the created subnet will support "shadow addresses".
This means all machines inside the subnet will have cloud-local addresses
configured, but there will also be a shadow address configured for each
machine, so that the machines can be accessed from outside the model (similarly
to the automatic public IP addresses supported with AWS VPCs).

This command is only supported on clouds which support creating new subnets
dynamically (i.e. Software Defined Networking or SDN). If you want to make
an existing subnet available for Juju to use, rather than creating a new
one, use the "juju subnet add" command.

Some clouds allow a subnet to span multiple zones, but others do not. It is
an error to try creating a subnet spanning more than one zone if it is not
supported.

---
Apart from that, I agree the add-subnet help text should be updated not to refer to create-subnet.