Update docs cell description vs. cell kind justification (#1237)

Fixes #1236

doc/concepts/recipe.rst

@@ -113,16 +113,15 @@ The steps of building a simulation from a recipe are:
 .. Note::
     An example of how performance considerations impact Arbor's architecture:
     you will notice cell kind and cell description are separately added to a recipe.
-    Consider the following conversation between an Arbor simulation, recipe and hardware back-end:
-
-    | Simulator: give me cell 37.
-    | Recipe: here you go, it's of C++ type s3cr1ts4uc3.
-    | Simulator: wot? What is the cell kind for cell 37?
-    | Recipe: it's a foobar.
-    | Simulator: Okay.
-    | Cell group implementations: which one of you lot deals with foobars?
-    | Foobar_GPUFTW_lolz: That'd be me, if we've got GPU enabled.
-    | Simulator: Okay it's up to you then to deal with this s3cr1ts4uc3 object.
+
+    It might seem like overkill to have a separate call that returns the cell
+    kind, when one could determine the kind by requesting the cell description,
+    then querying the kind of the result.
+
+    Some phases of model construction, however, only require the cell kind, and
+    not the full cell description, which can be quite expensive to
+    assemble; for example, a Purkinje cell model can have very complex geometry,
+    a rich collection of ion channels, and thousands of synapses.
 
 General best practices
 ----------------------