A container is, roughly speaking, a root file system image together with some things like resource limits and metadata about what volumes to mount, what processes to run, etc.
Garden is an API for creating and running container specifications. Anyone can write a server that implements the Garden API, the core Cloud Foundry teams maintain garden-linux, garden-runC, and garden-windows implementations.
A droplet is a "built" artifact created from source code that is typically mounted or streamed into a Garden container and then run. There are times where you do not want a separate droplet, and want to have your root file system as well as all source code and/or built artifacts baked into a single image. However, often, you do want this separation between the droplet, which represents your code, and the root file system. One major benefit is that CVEs present in lower level dependencies that are common to most containers can be uniformly repaired across all tenants and all running applications on the Cloud Foundry platform without any developers having to re-push their code. E.g. if there is a new patch required for something like openssl, and your Cloud Foundry installation has thousands of developers and hundreds of thousands of running Garden containers, it would be much better if an operator could roll out the openssl patch to all containers with a single command.
The Diego cell is a VM that's part of the Cloud Foundry architecture. Cloud Foundry itself is a distributed system with different components responsible for different things. There is a component responsible for user authorization and authentication, there are components for aggregating logs from applications, there is a component responsible for providing the developer-facing API for creating, scaling, and managing applications, etc. The Diego cell's are responsible for essentially taking requests to run containerized workloads, and running them. User requests to run an application are consumed by the user-facing API, and translated to a request to the Diego backend. Diego itself has several components, including a scheduler, and the scheduler's job is to select which cell to do a given piece of work.
You can think of the cell has having two components: (1) a Garden server for running containers, and (2) a representative that can represent that Garden server to the Diego scheduler, so rather than Garden having any Diego-specific knowledge (Garden can function in a standalone manner), the scheduler instead talks to each Garden's Diego representative on that same cell.
I'm not sure what "application VM" means in the quote you pulled out. Each application running on Cloud Foundry can be run with multiple parallel instances (for fault tolerance, better concurrency, etc.). Each application instance is running as a Garden container in some Diego cell. A production deployment of Cloud Foundry will have many Diego cells. Each cell can run many (up to hundreds) of Garden containers. For better fault tolerance, the Diego scheduler will attempt to place the instances of a given application on different Diego cells, rather than cramming them all into the same cell, since if that single cell goes down, your whole application goes down.
You do not need to create a new manifest to scale up BOSH deployments. Just change the instances value of whatever job/instance group you want to have more VMs of, and re-run bosh deploy.
