How are MongoDB's On-Demand Materialized Views On-Demand vs their Standard Views?

According to MongoDB's Docs:

Comparison with On-Demand Materialized Views

MongoDB provides two different view types: standard views and on-demand materialized views. Both view types return the results from an aggregation pipeline.

• Standard views are computed when you read the view, and are not stored to disk.
• On-demand materialized views are stored on and read from disk. They use a $merge or $out stage to update the saved data.

I have a few questions:

1. Why is the view that's persisted (aka Materialized) called "On-Demand"?
2. Why would you ever use a standard view if it's always calculated on the spot (you know, "on-demand")?
3. Does one create a "On-Demand" Materialized View purely by using a $merge or $out stage?

I asked their new AI chatbot, but it only made the confusion worse:

In MongoDB, standard views are predefined aggregation pipelines that are based on a collection. You can apply a set of permissions to a view that differs from the ones for the base collection. So standard views are a handy tool if you want to provide aggregated data to a special user group without granting access to the base collection. The drawback of these views is that the aggregation pipeline is run every time a query against the view is executed.

"On-demand-materialized-views" on the other hand is only a fancy term for a collection that contains pre-aggregated data. It is the responsibility of the developer or DBA to prepare and update the data in the materialized view. Often, this means to run a pipeline with a $merge or $out stage that writes the data to the materialized view collection, but you could also write the data to the materialized view when adding new documents. This can be done periodically or upon specific events that fit your use case. The "on-demand" stands for the demand of your application and use case in this respect.

From this point of view, "On-demand-materialized-views" is more a pattern than a technology. It is up to you to identify the materialized views that your application needs and the matching mechanism to update the data. A pattern that is closely related is the Computed pattern that describes that data that are repeatedly should be pre-computed so that they are available when reading the data.