I think it’s a mix.
From the perspective of the CDK constructs you are using, it is still a “heavy weight” thing in the sense that it marks the boundary of the CDK compilation.
From the perspective of the outer Pulumi code, it’s “just another Pulumi component”.
But you typically want to keep that CDK island quite coarse grained because imperative CDK operations only impact things within the CDK island (you can’t create one pulumicdk Stack, then another Pulumi resource, then use an imperative CDK operation to grant permissions to something defined in the pulumicdk Stack - since it will already be deployed at the boundary of the pulumicdk Stack).
For CDK library authors, I’d generally encourage not using pulumicdk directly - and just leaving it to your users to be able to consume your constructs from Pulumi via pulumicdk Stack - much like they consume your constructs from CDK using g awscdk Stack.