Q:

Azure: Why is it advised to use multiple storage accounts for a virtual machine scale set?

In the documentation for Virtual Machine Scale Sets it says

Spread out the first letters of storage account names as much as possible

I have two questions to this:

Why should you use multiple Storage Accounts at all?
Why is Azure creating 5 Storage Accounts if I create a new Virtual Machine Scale Set through portal?
Why should I spread the first letters as much as possible?

A:

It's about avoiding throttling

https://docs.microsoft.com/en-us/azure/storage/storage-scalability-targets

For standard storage accounts: A standard storage account has a
  maximum total request rate of 20,000 IOPS. The total IOPS across all
  of your virtual machine disks in a standard storage account should not
  exceed this limit.
You can roughly calculate the number of highly utilized disks
  supported by a single standard storage account based on the request
  rate limit. For example, for a Basic Tier VM, the maximum number of
  highly utilized disks is about 66 (20,000/300 IOPS per disk), and for
  a Standard Tier VM, it is about 40 (20,000/500 IOPS per disk), as
  shown in the table below.

There's is no price difference between 5 or 1 storage accounts, so why not 5?
If you create 5 SA in different Storage Rack/Stomp (Datacenter infrastructure) you have less chance to be throttled, and they have better chance to distribute traffic load. So I think those are the reasons

A:

The answer to this lies in the limits of Azure. If you look at the storage limits specifically, you will find that the storage account is capped at 20k IOPS.
Total Request Rate (assuming 1KB object size) per storage account  
Up to 20,000 IOPS, entities per second, or messages per second

So that means that your Scale Set would effectively be capped at 20k IOPS, no matter how many VM's you put in it.
As for the storage Account naming, I have no clue, but looking at the templates they are linking to, they are not doing it:
"uniqueStringArray": [
  "[concat(uniqueString(concat(resourceGroup().id, variables('newStorageAccountSuffix'), '0')))]",
  "[concat(uniqueString(concat(resourceGroup().id, variables('newStorageAccountSuffix'), '1')))]",
  "[concat(uniqueString(concat(resourceGroup().id, variables('newStorageAccountSuffix'), '2')))]",
  "[concat(uniqueString(concat(resourceGroup().id, variables('newStorageAccountSuffix'), '3')))]",
  "[concat(uniqueString(concat(resourceGroup().id, variables('newStorageAccountSuffix'), '4')))]"
],

I suspect, this may be somehow linked to how the storage accounts are distributed among nodes hosting them (so say accounts starting with 'A' are all hosted on the same cluster or near by clusters).

