That's a funny comparison. The much more obvious contrast would be to writing a Postgres extension in C.
Or are you asking, "why have native DBMS extensions at all?" Looking at the set of native Postgres extensions that currently exist would probably be enlightening:
• PostGIS, for one. You can't really define those types—and especially, the algorithms that operate on them—efficiently in PL/pgSQL. In this case, the extension is native for low overhead operation.
• uuid-ossp, for another. To generate the data it does, this extension needs access to several pieces of data from the OS (e.g. the MAC address of an Ethernet interface) that you can't access from PL/pgSQL. In this case, the extension is native to query native OS data APIs.
• Citus, for a third. Citus basically changes Postgres's runtime "operational architecture" in several fundamental ways. It augments the Postgres Postmaster, changes how replication works, etc. None of this is possible from PL/pgSQL. In this case, the extension is native to use native OS threading and IPC APIs to override how Postgres works.
(And that's ignoring the fact that having native extension support usually gets you ABI compatibility with the embeddable runtimes of most other languages, allowing you to then support things like Python or Java—and thus get access to low-overhead shared-memory+FFI-based "IPC" with existing libraries in those languages, rather than needing to have them run as co-servers and communicate over sockets. Which, in turn, gets you the ability to cheaply and easily use client libraries written in those languages to create Postgres Foreign Data Wrapper libraries for Datomic, or Elastic, or the AWS Public Dataset API, or whatever other weird-API-with-relatively-few-library-impls you like.)
A UUIDv1 contains the host's MAC address as a component. And the uuid-ossp extension (or rather, the OSSP's libuuid, which it uses) does indeed read said MAC address when building UUIDv1s: https://github.com/sean-/ossp-uuid/blob/master/uuid_mac.c
Keep in mind, if you're using uuid-ossp rather than just relying on Postgres's built-in gen_random_uuid() function, it's very likely because you want to generate UUIDv1s instead of UUIDv4s (as they're the only two types of UUIDs that see much use.) So this functionality is pretty essential to the extension—a version of the extension without it wouldn't be worth much.
Or are you asking, "why have native DBMS extensions at all?" Looking at the set of native Postgres extensions that currently exist would probably be enlightening:
• PostGIS, for one. You can't really define those types—and especially, the algorithms that operate on them—efficiently in PL/pgSQL. In this case, the extension is native for low overhead operation.
• uuid-ossp, for another. To generate the data it does, this extension needs access to several pieces of data from the OS (e.g. the MAC address of an Ethernet interface) that you can't access from PL/pgSQL. In this case, the extension is native to query native OS data APIs.
• Citus, for a third. Citus basically changes Postgres's runtime "operational architecture" in several fundamental ways. It augments the Postgres Postmaster, changes how replication works, etc. None of this is possible from PL/pgSQL. In this case, the extension is native to use native OS threading and IPC APIs to override how Postgres works.
(And that's ignoring the fact that having native extension support usually gets you ABI compatibility with the embeddable runtimes of most other languages, allowing you to then support things like Python or Java—and thus get access to low-overhead shared-memory+FFI-based "IPC" with existing libraries in those languages, rather than needing to have them run as co-servers and communicate over sockets. Which, in turn, gets you the ability to cheaply and easily use client libraries written in those languages to create Postgres Foreign Data Wrapper libraries for Datomic, or Elastic, or the AWS Public Dataset API, or whatever other weird-API-with-relatively-few-library-impls you like.)