Just curious what the benefit here is for you. Is it just that it seems unnecessary?

I also that example content should, if delivered, should always be disabled out-of-the-box.

Yes, that’s exactly my point. While I can see some didactic value for brand-new FME Flow admins doing their first install, I think most of these items are superfluous in a production environment. A lot of them feel like historical leftovers rather than practical necessities, and for new users they often create more confusion than value.
 

Users
The default users (user/guest/author) are disabled by default. They don’t really serve a functional purpose today and mostly duplicate what roles already cover. I usually delete them right away, while the roles themselves are very useful.
 

Workspaces

• Utilities/BackupConfiguration.fmw and its schedule should probably be a built-in FME Flow feature, not just a workspace calling the REST API. Editing the schedule to inject admin credentials is strange, and jobs often fail if FME_WEB_URL isn’t configured correctly.

• The Dashboard repository contains some interesting workspaces, but the dashboards system is scattered, overlapping, and inconsistent. We now have three different “dashboard-like” experiences: the home page (renamed Dashboard), the Jobs/Dashboard menu, and Analytics. I actually like the idea of shipping dashboard generators, but I think a single data-streaming workspace that outputs a unified page (with BRG* Transformers 👀) would be simpler.

• The Samples repository is only useful to me for quickly testing the environment without publishing my own workspace. For training or educational purposes, I think these would make more sense as downloadable Flow projects.

AR Apps
They are irrelevant unless you have an iPhone. If Safe wants to provide demos, these too could just be optional Flow projects from FME Hub.

Topics & Subscribers
This is the most frustrating part. As far as I can tell, topics/subscribers have been fully replaced by Automations. They’re only still there for backwards compatibility, but the presence of legacy content there is misleading. A common example: if someone wants to use “Email Result To” when running a job, it silently depends on a subscriber configuration that isn’t obvious, despite the fact that the system email is already configured in FME Flow.

It seems to me that the system email should handle password recovery, system events, and job results directly, without needing legacy subscribers.

This legacy system just adds complexity for new users who are not going to train on the notification framework, while they can (and should) use Automations instead.

In the end, I’d much rather have a fresh install feel like a blank canvas that I can build on. Imagine if every time you created a new workspace, Workbench dropped in a Tester, an AttributeManager, and an HTTPCaller by default. it would be distracting rather than helpful.

I totally agree. It’s good to have a sample workspace that can be run after installation to make sure everything is working as intended but that’s about it.

The System Email should be the default for the “Email results to” option and it should be made clear that that option won’t work if the System Email is not configured. Email actions in Automations (and heck… the Emailer transformer) should also be able to use the System Email. 

With new users on new installations we often see them use the Dashboards repository because the default Author role has access to it and it’s the first one that comes up in the list when publishing a workspace. During training we can quickly catch this fortunately.

I support the idea.

There are a couple of schedules and dependant workspaces that are useful: the backup and the dashboard ones. The rest would be good if optional (eg. an “Install sample data” tick box somewhere at the installation)

I was confused at my first upgrades when I restored the backup, if I need to overwrite the existing objects or not :D

On the topic of leaner installations and a clear split between core and satellite features, ​@alexbiz  , I advocated this approach years ago. The package system should allow to avoid installing non-essential components by default (e.g., ReframeReprojector). Even as AI matures to help navigate the transformer landscape, an ERP-migration user should not receive ArcPropertyExtractor ...