On a replica set, enabling profiling via db.setProfilingLevel(...) on a database (whether new or not) creates the system.profile collection (this seems implied by the documentation):

$ mongod
$ mongo --port 27017
> db.setProfilingLevel(2)
> show collections
system.profile 
>

However, on a replica set endpoint single shard cluster, enabling profiling on a new (i.e. not previously existing, or previously dropped) database behaves differently and does not make the system.profile collection visible:

$ mongod --setParameter featureFlagAllMongodsAreSharded=true --setParameter featureFlagReplicaSetEndpoint=true
$ mongo --port 27019
> db.setProfilingLevel(2)
> show collections
>

However, doing an operation that database, such as creating a collection, makes the system.profile collection visible:

> db.createCollection("xyz")
> show collections
system.profile
xyz

On a technical level, enabling profiling is creating the system.profile collection on the local catalog, but is not registering the database on the cluster catalog, so the collection exists, but is invisible to the user. This can be confirmed using the $listCatalog stage (NOTE: this example likely depends on SERVER-64980 not being fixed):

> show collections
> db.getSiblingDB("config").databases.find()
> db.getSiblingDB("admin").aggregate([{$listCatalog:{}},{$match: {db: db.getName()}},{$project:{name: 1}}])
{ "name" : "system.profile" } 

The behavior should be amended to match that of replica sets.