SQL Server Compact Edition
It's all got to do with keeping the footprint of SSCE small.
I very much doubt that your DB is twice as slow just because you are using nchar. I would even go as far to say that it's also not twice as large.
SQL Server 2005 Compact Edition stores rows on 4 KB pages, and it does not split rows across pages, except for text and ntext data types. Because all the pages are not always filled, some unused space exists on individual pages. Therefore, for your database to be twice as large, all your rows (in all your tables) would need to be more than 2 KB in size (as rows aren't split across pages) resulting in SSCE using more space. This is extremely unlikely so using char or nchar would more than likely result in a DB of equivalent size.
Cheers
Jeff
I guess one of the decisions was to remove those features that were similar. Therefore nchar and nvarchar won out over char and varchar to ensure that more than just English speaking countries could use SSCE.
With regards to how much code/footprint this saved, I'm guessing quite a bit as the way you process these types is different which could potentially result in duplicate code.
BTW, are you using Merge Replication If so, turn on data compression.