Hi,
Sometimes there are guidelines (such as KBs), which provides a generic recommendations which is so b'cos it may lead to performance issues later on. Now, the question is what type of performance issue? Which is generally covered in the Internal Kb (I guess).
Technically, you can have maximum 1 inode per WAFL 4K block (i.e max upper limit for inodes in a single volume), however by-default the ratio is : 1 inode per 32K blocks.
Example : Consider a 1TB volume.
-max inode = (1024 * 1024 *1024)/4 = 268,435,456 inodes
-min inode = (1024 * 1024 *1024)/32 = 33,554,432 inodes
Depending upon the size of the volumes, inodes are allocated, but if the file (small-size) consumption is very high then it will run out of the inodes even before the volume runs out of 4KB blocks.
My personal experience : I have increased the inodes count for couple of specific oracle volumes many times, sometimes 5%, 20%, and probably more times and have had no issues at all. As you may already know, as the inodes increases so does the inode-file size , inode-file is like a special meta-data file that stores entry of the all allocated inodes. For a typical linux-like system, OS will only load the in-core inodes in the memory which means ONLY files that are opened, so I assume the same for 'Ontap', so considering not all the 'trillion' files will be opened at the same time, we can rule out memory issues (for caching in-core inode file) and depending upon the Model, this could be very trivial.
However, the performance issue could come in to effect, if you are dealing with NDMP backups/restores or when the system is shooting through inode-file to determine which files needs to be backed up or which files have changed between snapshots. This is one area where a large inode-file (especially if it's not spread well across directories) can slow your backups/restores considerably. I don't know which other areas it could impact but apart of this, I don't see any issues in increasing the inodes count size (Unless the volume usage itself is between 80-to-100%).
Thanks!