Quite the opposite. If your application asks for more connections or there is a connection leak, your data source will fail. The theoretical maximum number is dictated by the maximum number of connections your DB will allow. For a moderate load this comes to about 100-300 connections when several applications are using the same database. For heavy loading this value can increase, but that depends on your definition of load.
The practical value is dictated by the max concurrent connections value of your data source. If this value is 100, a safe bet is to usually set it to N + 50% N where N is the maximum number of concurrent connections. Once again this is a generic thumb rule and should be aligned to the growth of connections in your application.
In our produktion environment the typical number of connections is set to 10.
This is sufficient for us because the highest number of parallel connections is about 6 at a time.
If you have a lot of long lastig queryies that eat up your free connections then you might have a problem and get a lot of waiting connections and your performance will suffer or program faults due to timeouts.
Try to figure out how many parallel connections you have in your environment before setting the value to high (100 seems way to high for me!).
The company I am working for has about 3500 Users working with our WLS.
We once had a datasource that was accessed by about 15+ applications. Each application had an average maximum concurrent connections of 8. Under such cases the number of connections to be served is pretty high. It depends on overall load and 100 was used as an example.