remove description about "scale jobs"

docs/concepts/workloads/controllers/jobs-run-to-completion.md

@@ -257,8 +257,7 @@ The tradeoffs are:
 
 - One Job object for each work item, vs. a single Job object for all work items.  The latter is
   better for large numbers of work items.  The former creates some overhead for the user and for the
-  system to manage large numbers of Job objects.  Also, with the latter, the resource usage of the job
-  (number of concurrently running pods) can be easily adjusted using the `kubectl scale` command.
+  system to manage large numbers of Job objects.
 - Number of pods created equals number of work items, vs. each pod can process multiple work items.
   The former typically requires less modification to existing code and containers.  The latter
   is better for large numbers of work items, for similar reasons to the previous bullet.

docs/tasks/job/parallel-processing-expansion.md

@@ -184,11 +184,6 @@ If you have a large number of job objects, you may find that:
 - Even using labels, managing so many Job objects is cumbersome.
 - You exceed resource quota when creating all the Jobs at once,
   and do not want to wait to create them incrementally.
-- You need a way to easily scale the number of pods running
-  concurrently.  One reason would be to avoid using too many
-  compute resources.  Another would be to limit the number of
-  concurrent requests to a shared resource, such as a database,
-  used by all the pods in the job.
 - Very large numbers of jobs created at once overload the
   Kubernetes apiserver, controller, or scheduler.