When you use client-go, you step away from the declarative interface to Kubernetes, much like when using Pulumi to step back from the TF interfaces. Kubernetes has itself strayed from being purely declarative and provides several mechanisms for transforming and modifying incoming resources during the admission and scheduling process, so you cannot actually be sure what you submit is what will be running anymore.
Again, declarative vs imperative is a DX issue. All the systems underneath are using both. So if we follow your logic, that the underlying system is what matters, every experience would be both imperative and declarative. Kubernetes and Terraform both use imperative processes to implement the declarative input. Using the properties of the underlying system to describe the exposed DX makes no sense. You don't get to add imperative on declarative or declarative on imperative and claim it has the property of the system you just layered on top of. The outermost layer, the one exposed to the end user, is the type of system (declarative or imperative) that the user is using. Pulumi and client-go are both imperative interfaces on top of other systems.
Again, declarative vs imperative is a DX issue. All the systems underneath are using both. So if we follow your logic, that the underlying system is what matters, every experience would be both imperative and declarative. Kubernetes and Terraform both use imperative processes to implement the declarative input. Using the properties of the underlying system to describe the exposed DX makes no sense. You don't get to add imperative on declarative or declarative on imperative and claim it has the property of the system you just layered on top of. The outermost layer, the one exposed to the end user, is the type of system (declarative or imperative) that the user is using. Pulumi and client-go are both imperative interfaces on top of other systems.
Go fish...