If the primary usage is heavy scientific processing where you need to visualize complex 2D/3D scenarios then this library is not for you. In this case it is probably better to use one of the scientific tools like Matlab or Maple.
In addition, if you for example intend to implement a large scale project planning tool with several thousand activities that you want to manipulate and display using the support Gantt charts in this library this is probably stretching it a bit too far. Again, this is probably better done with more dedicated tools like MS Project.
In addition may we again point out that the library does not officially support any 64bit OS due to issues with PHP/GD.
Some of the 2D barcodes will simply not work in a 64bit OS. This is consequence of the computation of the error correcting codes which in some instances assumes 32bit integers. For the basic graphs there is no known issues but since the library is not verified on a 64bit OS we do not officially support this.
There is also a question on sever load that should be taken into account. Due to the CPU intensive nature of image processing the complexity of the generated images needs to be kept as low as possible for any sites that would expect heavy load. Since it is normally necessary to increase the allowed memory for PHP (see Setting up your php.ini file) when working with images this could easily make the server hit it's physical memory limit if the load is very high.
For example, the practical lowest memory that should be set for PHP when working with images is 32MB (recommended is at least 64MB), if your system must cope with 50 simultaneous users it means that the HTTP processes alone will need roughly 1.6GB just to secure the basics. Handling 50 simultaneous executing image scripts will also require some heavy processing and the server needs to have a CPU capacity to handle this. Some discussions about dimensioning a server can be found in Efficient graph generation using the built-in cache subsystem.