Simply:

SELECT date_trunc('hour', timestamp) AS time, count(*) AS metric
FROM  (
   SELECT timestamp FROM utilities
   UNION ALL
   SELECT timestamp FROM items
   ) sub
GROUP  BY 1
ORDER  BY 1;

Clashing IDs are not relevant to this query. Simply append rows from both tables with UNION ALL (not just UNION!), use date_trunc() and aggregate.

I removed a more complex query that would only make sense with (unlikely) expression indexes on underlying tables.

If you like negligible performance gains, you can overcomplicate things with the overkill below. It results in an emulated index skip scan:

with recursive cte as (
  (select date_trunc('hour',recorded_at) as t,count(*)
  from utilities
  group by 1 order by 1 limit 1)
  union all
  select lat.t,lat.count
  from cte cross join lateral
  ( select date_trunc('hour',recorded_at) as t,count(*)
    from utilities
    where date_trunc('hour',recorded_at)>cte.t
    group by 1 order by 1 limit 1) lat )
,cte2 as (
  (select date_trunc('hour',recorded_at) as t,count(*)
  from items
  group by 1 order by 1 limit 1)
  union all
  select lat.t,lat.count
  from cte cross join lateral
  ( select date_trunc('hour',recorded_at) as t,count(*)
    from items
    where date_trunc('hour',recorded_at)>cte.t
    group by 1 order by 1 limit 1) lat )
select t,coalesce(cte.count,0)+coalesce(cte2.count,0) as count
from cte full join cte2 using (t);

If you set up 2 tables, populate them with 100k random timestamps each, eqip both with a covering index on expression:

select setseed(.42);

create table utilities(recorded_at)as 
select (now()-random()*'3 months'::interval)::timestamp
from generate_series(1,1e5);

create table items(recorded_at)as 
select (now()-random()*'3 months'::interval)::timestamp
from generate_series(1,1e5);

create index utilities_idx on utilities(date_trunc('hour',recorded_at) asc)
  include(recorded_at)--necessary to upgrade index scan to index-only scan
  with(fillfactor=100);
create index items_idx on items(date_trunc('hour',recorded_at) asc)
  include(recorded_at)
  with(fillfactor=100);

Then make sure they are freshly analysed (and actually even clustered to help out seq scans), you’ll find how little this much code and effort contributes to performance:
_{explain plans and performance tests at db<>fiddle}

It does look like 30%, but that’s 30% of very little already – and it’s a bit of a pain to get there.

An interesting observation is that not only is the index strictly necessary for this to work, it also has to be additionally weighed down to include the raw timestamp as payload on top of the date_trunc() expression just to enable an index-only scan, even though the query never uses the raw timestamp, making it feel like it’s just an expensive way to parley with the planner.
Meanwhile, the seq-scanning queries don’t really need the index at all.

count is an aggregate function which combines the values of multiple rows together. You have to tell Postgres how to group rows with a group by clause. You want to group by hour, so GROUP BY date_trunc('hour', timestamp) or GROUP BY 1.

Also, you do not want to do a cross join which will result in each row in one being joined with every row in two. Instead you can union both tables together and then group, but this can’t take advantage of indexes. Instead, count both tables (which can use an index), then union and group and sum the counts together (only a handful of rows).

WITH hours AS (
  SELECT 
  date_trunc('hour', recorded_at) as "hour", 
  COUNT(*) as "count"
  FROM utilities
  GROUP BY 1

  UNION ALL

  SELECT 
  date_trunc('hour', recorded_at) as "hour", 
  COUNT(*) as "count"
  FROM items
  GROUP BY 1
)
SELECT 
  "hour",
  SUM("count") as "count"
FROM hours
GROUP BY "hour"
ORDER BY "hour";

Demonstration.

Other notes…

• Ordering the subqueries will just slow things down. Only the final query needs to be ordered.
• Avoid naming columns using keywords like timestamp. They risk errors and don’t have a lot of descriptive power. Follow the thing_at for timestamps and thing_on for dates.
• There are a lot of SQL keywords and they’re hard to avoid, quote them if you use them to avoid ambiguity and bizarre errors.