Hello,
I don’t think that you can give an definitive answer to your question. It depends on many topics - e.g. backup window size, wanted speed of restores and so on.

Tim Smith did a sizing session at VeeamOn. It tells you exactly what you need to know for sizing the single  components in your VBR environment. See at www.veeamon.com

Hi @JustineP look at this link sorry it's only in italian language but useful.

Lo zen e l’arte del corretto dimensionamento (veeam.com)

The design of a Veeam infrastructure depends on many factors, the amount of VMs to be backed up and their relative size, and above all on the time and RPO required by the customer.
I tend to use a VBR+DB server if I don't have more than 1000 VMs, plus a Proxy/Repo/WAN server to scale up quickly as needed.

As noted here there are many factors and checking out Tim's session is to me the best starting point along with the links you sent.

From a VBR component standpoint, which is mostly what Simple vs Advanced is about, as mentioned above by @JMeixner and @Chris.Childerhose ...’it depends’. Which one you go with isn’t really about data size necessarily, but maybe partly that and partly what an org has to use, resource-wise for the backup environment. Some things to consider as was already mentioned above - How many VMs do you/ your customer have? Is it VMware or Hyper-V? What is the total VM data size (in TB?)? What is the allowed backup window? What are the RPOs? Etc.

I’ll take a guess here without having more information about the environment. I’ll assume VMware and a relatively small org of maybe 100 VMs and maybe a total of 10TB. If this is the case, I would use a ‘hybrid’ approach of sorts. Have VBR on it’s own VM, and have Proxies on VMs as well. If you have available physical hardware, you could use them as combo boxes for both Proxy and Repository (as I do). For the fastest backup speeds, it’s best to implement DirectSAN, using physical servers as combo boxes (Proxies and Repos) 1. to save on h/w, OS, cooling/power, FTE costs; 2. Simplify the environment. But, with a small environment, that may even be more than what is needed for fast backup times. You could instead go with the ‘hotadd’ transport (backup) mode using VMs as Proxies and attain close to the same backup speeds. Although, you would have a bit of cost for OS and maintenance (OS upgrades, etc). If security is important, VBR v11 now has ability to implement immutable storage for your Repo with hardened Linux Repo. Just a bit of info for you to ponder on though.  

How many jobs can you have? Well, for reference you can have 10 concurrent jobs running per CPU core and 5 GB RAM on the VBR server. The rule of thumb is if using per-VM setting in the Repository, you can have a lot of VMs (over 100-200) in a job; if not using per-VM, about 30-40 VMs in a job. Again..as mentioned, it depends on the resources you give the VBR server, and the resources you have for your Proxies and Repositories, as well as backup windows and RPOs.

Here is Tim’s video session as was suggested above to watch:
https://www.veeam.com/videos/vbr-sizing-17277.html?rwty

Hope this at least gives you a bit of help on how to begin. 

Cheers!

As @JMeixner , @coolsport00 , @Link State  and @Chris.Childerhose , it all depends on the requirements of the customer.

What RPO and retention needs to be implemented? Are you using weekly synthetic fulls, or active fulls needed? What is the change rate? How many VMs you want to backup? Do you want a daily copy ? Do you want to use a virtual VBR-server or physical?

In the first choice, advanced deployment is needed.

Which transport mode will you use using vSphere? Physical with direct connection to the storage? What storage on the hypervisor are you using?

If not using a direct connection to shared storage, hot-add transport mode is recommended, deploying 1 or more virtual proxy-servers, …

As you can see, a design is not always that easy.

Experience is here the key in combination with having as much info as possible at the beginning ;-) !