This problem is specific to using a summed pricing attribute, because the data stores the attribute as the actual value, as opposed to a level index (i.e. brand is stored as 1/2/3 etc., while price is stored as $1,450, $989, $2,381 etc.).
By using scripting to dynamically change the price for different respondents, the data will be recorded with the different price values (i.e. 989 for a respondent from the United States, but 55,750 for someone from Russia).
If you can get away with not having a summed pricing setup, but just doing a normal price attribute with set levels, you're in a much better position. I wouldn't say there is a drawback of treating price as a normal variable. Most people that end up using a summed pricing approach do so to try to make the pricing a bit more realistic (products full of good levels should, on average, cost a lot more than products made up of not so good levels).
Conjoint studies with price a normal attribute with discrete level is probably the vast majority of exercises done, so definitely nothing wrong there. If changing the actual value shown based on different currencies, it would make a lot of sense to make sure you are showing and modelling the same thing (it would be weird to show a large range of price in currency 1 and then show a small range in price of currency 2 and then combine everything for estimation). It would also seem like using the currency group as a covariate in the HB estimation would be a good idea.