I think I can summarize it in a rough, general way.

  CI/CD is a method to automate tasks in the background that you would otherwise run on your laptop. The output
  of the tasks are used as quality gates for merging commits, and for deployments.
  
  - Step 1. Your "laptop in the cloud" requires some configuration (credentials, installed software, cached artifacts)
    before a job can be run.
    - Requires logic specific to the CI/CD system
  
  - Step 2. Running many jobs in parallel, passing data from step to step, etc requires some instructions.
    - Requires logic specific to the CI/CD system
  
  - Step 3. The job itself is the execution of a program (or programs), with some inputs and outputs.
    - Works the same on any computer (assuming the same software, environment, inputs, etc)
    - Using a container in Step 1. makes this practical and easy
  
  - Step 4. After the job finishes, artifacts need to be saved, results collected, and notifications sent.
    - Some steps are specific to the CI/CD system, others can be a reusable job
  
  Step 3 does not require being hard-coded into the config format of the CI/CD system. If it is instead
  just executable code in the repo, it allows developers to use (and work on) the code locally without
  the CI/CD system being involved. It also allows moving to a different CI/CD system without ever rewriting
  all the jobs; the only thing that needs to be rewritten are the CI/CD-specific parts, which should be
  generic and apply to all jobs pretty much the same.
  
  Moving the CI/CD-specific parts to a central library of configuration allows you to write some code
  once and reuse it many times (making it DRY). CircleCI Orbs, GitHub Actions, Jenkins Shared Libraries/
  Groovy Libraries, etc are examples of these. Write your code once, fix a bug once, reuse it everywhere.