I was recently teaching a SharePoint class, and during the BDC section I ran into a situation where I had to explain why you could have multiple LobSystemInstances in a given LobSystem definition.

At first it didn't make very much sense to me for a number of reasons:

1. Database vs. Web Service: you are constrained to using all Database or all Web Service connections in a given LobSystem (this is defined at the LobSystem object, not at the LobSystemInstance)
2. You must have the same schema for all LobSystemInstances: there is no way to specify different Methods for entities based on each LobSystem. 

So to me, it seemed like you were effectively stuck for a given LobSystemInstance.  Then I started reading the documentation on the MSDN and found the following:

The LobSystemInstance object allows you to associate two sets of instance-specific data such as connection parameters and authentication settings with a single system definition - one for Web clients and one specifically for search. This is extremely useful when you have different sets of security credentials to access data using Web clients and to crawl search.

So there you have it.  But you have to ask yourself, how would I pick different LobSystemInstances.  Well, when you look at the BDC picker in SharePoint, you'd naturally think it's enumerating on the LobSystem.  Well, you're wrong.  It's enumerating on the LobSystemInstances.  So you can effectively pick different connectionStrings for your Search vs. Web Client.

I have a feeling this would also help when doing shifts between Dev, Staging, and Production.  I imagine you could have all of the different strings in one Application file.  But it's too early to tell whether this is a best practice or not. 

Further reading (suggested):

MSDN LobSystemInstance definition

MSDN Business Data Catalog FAQ (not too much there yet - but a good start)