As a general rule of thumb, the nonvolatile (Serial Flash/EERPOM) size has to be slightly bigger than the application code size (also need some space for configuration and storing pairing/link keys). If Over the Air (OTA) upgrades are needed, you need 2x this size. There is no upper limit on the size of the nonvolatile, but it should be noted that EEPROMs are limited to 64KBytes because they use 16 bit addressing. At least this is my understanding.
Regarding EEPROM, I should also note that the team has used larger 128KByte EEPROMs as well.
These will work with fine with the the BCM2073x, but only the lower 64KBytes will be used/accessed by the firmware.
On the other hand, the EEPROM driver API provides low level access to write to any EEPROM location, so the application can still use the upper 64KBytes by specifying a different I2C slave address than the one used for the lower 64KBytes, which is usually 0xA0/0xA1 (some parts also use 0xA2/0xA3 while others use 0xA8/0xA9).
However, they cannot use this space to store app/patch code/configuration – only the apps own data using the raw EEPROM read/write API (note that none of the bleprofile_*NVRAM API will work with the upper 64K).
Note that the 16b/64k limitation is an EEPROM architecture issue more than a firmware related one. EEEPROMs always use 16 bit addresses, which limits their size to 64KBytes. The way EEPROM vendors work around this is to use a different slave address for the higher 64KBytes (so the same 16 bit address space is mapped to a physically different slave).