Adding nextval() to a select caused hang/very slow execution

Noob here, so please bear with me.  The SQL I'm presenting is part of a larger PL/PGSQL script that generates generic "counts" from tables in our database.   This is code converted from an Oracle database that we recently migrated from.

I have a strange situation where a base query completes in about 30 seconds but if I add a nextval() call to the select it never completes.  There are other processes running that are accessing the same sequence, but I thought that concurrency was not an issue for sequences (other than skipped values).  

We are running on Google Cloud SQL v12 (I believe it is currently 12.3).  We are configured with a failover replica.  The VM configured is 8 vCPUs and 16GB of RAM.  PgAdmin shows that our cache hit rates are around 99%, as does this SQL:

We run autovacuum.  work_mem = 131072.  

The base SQL without the nextval() call and plan are at:  https://explain.depesz.com/s/T3Gn

While the performance is not the fastest, 30 seconds for the execution is acceptable in our application.  We only run this once a month.  I am not looking to optimize the query as it stands (yet).  The only change that causes it to be extremely slow or hang (can't tell which) is that I changed the select from:

select unnest(....

to

select nextval('sbowner.idgen'), unnest(....

Here are all the tables/views involved, as requested in the "Slow Query Questions" FAQ.  

I am aware that the structure of these views leaves A LOT to be desired, but I don't think they have a bearing on this issue, since the addition of nextval() is the problem.    We are going to restructure all of this and remove many layers eventually.  Before subjecting the reader to this long list of views, here's the theory.  We have customers and orders for various products.  Those products are grouped together into "lists" that can be selected.  Some products could be in more than one list.  At the same time, some products are "pre-release", so they are only reported internally and omitted from these counts.  Next, some of the orders are "autoship", meaning that the customer has subscribed to receive the product automatically.  Any customer with an autoship in the same category of product is to be omitted from these counts.  

As there are many of these "lists", there was a naming scheme created in the Oracle database we converted from.  Oracle allows synonyms so that we could create one view and rename it to match the naming scheme.  PostgreSQL does not allow that, so instead we had to create views on views to keep the names intact. 

The views/tables involved are:

                     Table "lruser.count_tempcols"
  Column   |            Type             | Collation | Nullable | Default
-----------+-----------------------------+-----------+----------+---------
 typecode  | character(1)                |           |          |
 disporder | smallint                    |           |          |
 mindate   | timestamp without time zone |           |          |
 maxdate   | timestamp without time zone |           |          |
 fmtdate   | character varying(10)       |           |          |