I'm running a Linux computer with 'LANG=en_US.iso885915'.
That's completely irrelevant - it's just the user interaction on the shell that is affected by those encoding sections. You have to think more in webserver terms: the shell may well be in iso8859-1, while content of the pages your webserver delivers might be in any other encoding - could be chinese, could be hebrew, could be unicode (and in the case of coppermine, it should be unicode, because that's what Coppermine was designed to be used with).
I'm running a Linux computer with 'LANG=en_US.iso885915'.
phpinfo() returns : HTTP Response Headers text/html; charset=ISO-8859-15
PHPinfo is of course in iso8859-1 as well, as it basically is just an HTML page generated by your server - it can be in any encoding the coder has decided to use.
Why is the Western (iso-8859-1) there?
Western encoding is there for historical reasons, for users who have upgraded from cpg1.3.x. As you started with a fresh copy of cpg1.4.x, you shouldn't have modified the language file and the encoding, but you should have left the recommended default encoding (utf-8) as it was set to and keep your fingers off the language file. Now it can be a bit tricky to switch: basically, you just set the encoding in coppermine's config back to utf-8 (as suggested above: you shouldn't have changed it in the first place). This will work fine for content added from the moment you switch to utf-8, however you might have issues with textual content inside your database (file titles, captions, comments etc.). You might have to convert those db entries from iso8859-1 to utf-8, using coppermine charsetmgr.php tool (which will work if you have iconv available on your server).