docs: update Kubed comparison

Incorporating @eshelyaron's feedback on earlier version of the comparison [here](eshelyaron/kubed#3 (reply in thread)).

Author: jinnovation

docs/explanations/comparisons.md

@@ -64,20 +64,29 @@ than [kubel].
 
 ## [kubed]
 
-There is considerable overlap in functionality between Kele and Kubed. I highly encourage you to try
-both out and see which fits your workflow best!
-
-[Kubed] is a Kubernetes management package that wraps `kubectl` commands and emphasizes
-comprehensive cluster exploration through a centralized Transient-based interface.
-
-Kele differs fundamentally in its architecture and design philosophy. Rather than wrapping `kubectl`
-commands, Kele communicates directly with the Kubernetes API via HTTP using ephemeral proxy
-processes, implementing its own API client layer with baseline caching of fetched resources and
-metadata. This proxy-based architecture enables its universal support for custom resources from day
-one, treating them identically to core resources through generic implementation
-patterns.
-
-Kele's dynamic permissions detection allows it to gracefully adapt functionality based on
+Like Kele, [Kubed] is a Kubernetes management package for Emacs.
+
+Functionally, there is considerable overlap in functionality between Kele and [Kubed]. I highly
+encourage you to try both out and see which fits your workflow best! The differences between the two
+packages lie primarily in architecture and design.
+
+One of the biggest differences between Kele and Kubed is that the latter **avoids 3rd-party
+dependencies**. This makes it that much more feasible to add Kubed to core Emacs in the future, if
+desired. In general, Kubed aims to "make the most" out of core Emacs integrations. For users that
+would like to minimize the number of transitive package dependencies they introduce to their
+workflow, this aspect of Kubed can be appealing.
+
+Conversely, Kele takes considerable liberty with its use of 3rd-party packages in the name of
+providing extended functionality. For example, Kele leveragess
+[`plz.el`](https://github.com/alphapapa/plz.el/) heavily in its direct communication with the
+Kubernetes API via HTTP using ephemeral proxy processes. This approach differs considerably from the
+other packages in this list, which by and large tend to rely on invoking the `kubectl` CLI in
+sub-processes and parsing the resulting shell output. We believe that the HTTP-API-based approach is
+not only more robust, but also allows for greater flexibility in the Emacs layer as a result. For
+example, this proxy-based architecture enables its universal support for custom resources from day
+one, treating them identically to core resources through generic implementation patterns.
+
+Similarly, Kele's dynamic permissions detection allows it to gracefully adapt functionality based on
 cluster-reported permissions, making it suitable for users with restricted cluster access while
 maintaining its "piecemeal" philosophy of quickly retrieving targeted information with minimal
 context-switching. Conversely, Kubed is based around "binding" package functionality to resources