The high level basics are that with caching enabled it should check for a cached price and return the first match found, and if no cached price is found only then will it go on to calculate based on formulas and/or check the database.
If you intend to have different pricing based on customer roles, or categories, or tiers, coupons etc. then there is a chance it will return the incorrect price from a previously cached situation, contrary to your intent for the current customer.
So if your pricing is the same across the board for everyone in every situation it is safe to cache. Otherwise, disable that cache setting and let it determine the price per situation. It may be more nuanced then that, but you'll need to dive in to the caching system to see how it works from the inside.
The first cache exclusion I found was in GetFinalPrice in the
PriceCalculationService, but there's also various pricing methods for attributes, variants, discounts, as well as probably a host of other situations. It may check for cached pricing several layers up or in any number of places, and you would need to step through the code to drill down to all the specifics.
var cacheKey = _cacheKeyService.PrepareKeyForDefaultCache(NopCatalogDefaults.ProductPriceCacheKey,
product,
overriddenProductPrice,
additionalCharge,
includeDiscounts,
quantity,
_customerService.GetCustomerRoleIds(customer),
_storeContext.CurrentStore);
//we do not cache price if this not allowed by settings or if the product is rental product
//otherwise, it can cause memory leaks (to store all possible date period combinations)
if (!_catalogSettings.CacheProductPrices || product.IsRental)
cacheKey.CacheTime = 0;