Subtle differences in the semantics of pub/sub and message passing services can have really significant consequences for their use-cases.
Google Pubsub is at-least-once delivery, and best-effort ordering. That means any consumer pipelines need to be able tolerate duplicates and out-of-order messages - in many cases, that's not trivial to handle. If the order of your messages isn't that important, and if you can make the operations of consumers idempotent - pub/sub is awesome. But more often than not, it becomes just another message passing service to add to your plethora of message passing services, because its limitations can't extend to all of your use-cases. (I really want one ring to rule them all - Kafka gets the closest, IMHO)
Kafka is an basically pub/sub on top of an ordered, append-only log, and consumers read the log stream very much like a single process reads/seeks on a file handle - using offsets. Given infinite storage - your entire data stream can be replayed, and any data can be recreated from scratch - thats a pretty awesome thing.
Try Apache Pulsar: https://pulsar.incubator.apache.org/
If you just want an event stream with loose ordering, no throughput or partition management, and the ability to 'ack' each individual message, than GCP pubsub is a pretty good choice. It can also do push-based subscriptions. The client libraries are rather buggy though and end up with memory leaks and network failures.
Kafka meanwhile is much more compatible with many other services that are typical run these days from stream processing to databases. That being said, Kafka is also pretty easy to run and VMs are extremely reliable on any cloud so I don't see much value in managed solutions for that, unless someone just wants to completely de-risk. The bandwidth costs add up quickly for even moderate usage.
Confluent is run by the same folks from LinkedIn who built Kafka originally (it talks about this a bit more in the article), so you're in good hands with regard to the product's vision remaining consistent to the original innovation.
This enables different kinds of use cases, and can be easier to reason about.
The downside is kafka doesn't provide guaranteed delivery out of the box, the producers buffer messages and that's when the loss can happen - if you need guaranteed delivery then you need to write extra code.
I know I found it a bit non-trivial to run, so if I was still using Kafka on GCP boxes anyway I'd absolutely try this out.
If you are comfortable at operations you'll be fine. Some people are not good at ops so outsourcing the problem making the ops side someone else's issue can also be useful.
Self hosting will offer far more options when it comes to scaling and tweaking. Overall on bare hardware costs it's cheaper and faster although up front costs will be higher.
Kafka usecases are rarely elastic so don't gain that advantage in the cloud. Also Kafka's missing tierd storage makes it expensive if storing big volumes of data.
In practice, it’s better to offload things that are not core to what your company is making money on, until you hit constraint points from scaling. As one of the comments mentioned, at PB-scale processing, even bare metal may make sense. (But not always - one of my former employers went down this path early and ended up losing all productivity in R&D because of people fighting to keep that baremetal setup alive for months on end. This really hurt future revenue growth and distracted eng. leadership from key changes in their industry.)
Like with most complex questions, the immediate answer is “it depends”.
