What are the security implications of the privileges needed by the Bluemedora Postgres account?
The big security problem here is that it doesn't revoke execution on its created functions from PUBLIC, which means that users other than bluemedora can use them, which is evidently not what is intended.  For pg_stat_statement this isn't really a problem, as it is located in a schema that no one else should have access to, but for explain_this it is in public schema and with PUBLIC execution rights.  And why is explain_this created in public in the first place?  If there is a reason to spread the functions over two schemas, I don't know what it is.  It looks like maybe explain_this was added to the script by someone who didn't know what they were doing.
Granting SELECT on all those catalog table is unneeded on most installations, as those already have SELECT granted for PUBLIC.  However, there is no guarantee this script will be run on &quot;most installations&quot;, so it is reasonable to explicitly grant those permissions rather than relying on someone having not mucked with the defaults.  Most concerning to me would be the lack of schema qualification on those grants.

Based on the info present an attacker could find out the names of
users and superusers of the db, all the tables being used and with the
queries probably a good deal of the table structures. Which could then
be used to craft a targeted attack.

All of those things except for query text will be true for almost any compromised user, even with no special permissions granted.  Are you worried about social engineering attacks?