P15 has the Euro sign, an amazingly common thing to need for businesses.
When you change charactersets with export/import, you must be careful of the automatic changes Oracle makes. It usually does the right thing, but it can go amazingly wrong, especially with some names in different languages or when vendors write their own data types.
You might look up the csscan utility and check the Globalization Support forum.
What is the common platform for your end-user clients? Is it Windows? If yes, forget WE8ISO8859P15. Use WE8MSWIN1252.
jgarry's answer signals an important problem that you can potentially have in your database. Depending on your applications, their client platforms, technology, and NLS settings, your database may already contain characters that are not valid in WE8ISO8859P1 but are valid, for example, in WE8MSWIN1252. Export/Import will corrupt such characters. They can be saved but a proper migration strategy should be applied. Could you tell something more about your software architecture, including the exact DB version?
I'm rusty on this, so corrode anything I say here with a lot of salt, but I seem to recall people saying the use of the Windows code set for the database is the wrong way to go. nls_lang faq says use Unicode.
It depends among what you choose. If you want to migrate with minimal effort, avoiding any data expansion problems in conversion and any need to adapt your applications to deal with a multibyte database character set, then WE8MSWIN1252 is usually the best single-byte character set for US and Western European use, because it corresponds to the most prevalent client platform and has the richest character repertoire. However, AL32UTF8 (Unicode) is the ultimate goal and recommendation. It is a prerequisite for any truly multilingual system that is not restricted to Western Europe only. (Note: WE8MSWIN1252 cannot even support all EU countries.) The quicker you migrate to AL32UTF8 the less work you will have with the migration. This is because databases tend to grow with time and become polluted with unexpected data. Later, the database will be larger, but your company may be larger as well and not able to tolerate long downtime. You see the pattern, right? ;-) Therefore, if you have resources to migrate to AL32UTF8, do this. If not, look at WE8MSWIN1252, but consider issues mentioned in my previous answer as well.
That is one of the better justifications I've seen, thanks.
There is a great ML document
Choosing between WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252 as NLS_CHARACTERSET [ID 264294.1]
which in line with what others already suggested, and I agree that you should stick to AL32UTF8 flexible globalization support in your application is important and you want to avoid headaches in the future with export-import to a database when you'll need all of a sudden a new region to support.
8859p1 is binary subset of win1252 (no recoding is needed). So in this case choice is simple.
8859p15 is logical subset of win1252 (the latter has all characters that p15 has, but they may just have different codes).
Bottom line. AL32UTF8 whenever you can. If you got to use one-byte charsets and sacrifice flexibility of Unicode, use we8mswin1252 for western European languages.