It could, but if it were, it would complicate the code without adding actual benefits and taking away some readability.
The disadvantages in this case include:

1. Utility attributes (_choices, _product_to_item_type) would have to become methods or be moved elsewhere;
2. Direct mapping or referencing of values will no longer be possible: ProductType.DONATION is no longer a string value that can be used, meaning that all the code that currently conviniently uses ProductType.DONATION will have to use ProductType.DONATION.value;

@classmethod
def as_choices(cls) -> Tuple['ProductType', str]:
    return (
        (ProductType.ELECTRONIC_SERVICE.value, 'Generic electronic service'),
        (ProductType.DONATION.value, 'Donation'),
    )

def get_taxable_item_type(self) -> Optional[pyvat.ItemType]:
    """Returned pyvat's ItemType matching our ProductType.

    Out of supported types -- donation and electronic service, only the latter is taxable.
    """
    if self == ProductType.ELECTRONIC_SERVICE:
        return pyvat.ItemType.generic_electronic_service
    return None

3. There will be an artificial difference between the value of the column Product.type and the values of enum, which would require keeping in mind where it has to be a .value and where just passed as it is, which seems completely unnecessary:

type = models.CharField(
    choices=ProductType.as_choices(),
    default=ProductType.DONATION.value,
    max_length=20,
    help_text='The nature and type of goods or services supplied (for tax administration)',
)

    ...
    # in update_tax
    ...
    product_type = self.plan.product.type
    self.tax_type, self.tax_rate = customer.get_tax(product_type=ProductType(product_type))
    ...

Enums are useful when used for enumeration, mapping attributes to strings not so much, and this class is added only to add syntactic sugar for CharField choices.

Refactored both ProductType and TaxType into enums, seems to be indeed better all in all.

It's used in looper.models.Product to define Product.type choices, it doesn't make sense to make it private though (renamed _choices to choices).

dict.get(key, value=None) returns None when key is not present (unlike getattr which doesn't have a default value for value).

$ python
Python 3.9.2 (default, Feb 20 2021, 18:40:11) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> {}.get('foobar') is None
True
>>> 
$ python3.6
Python 3.6.12 (default, Jan 15 2021, 09:51:15) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> {}.get('foobar') is None
True
>>> 

Same as the above: I don't think trading readable code for better type declarations makes sense here.

Oh, the second sentence has somehow lost a not so it makes no sense at all.

Should at least be the following:

In other scenarios taxes are not charged

I've rephrased the comment to only refer to supported scenarios:

In other scenarios, such as donations and sales to non-EU countries, taxes are not charged.

This comment was moved to ProductType's docstring, because there is where the described tax logic actually resides.

I've rephrased the comment so that it clearly refers to the SharedFields.tax_type and explains why NO_CHARGE is a blank string.

same as the other _choices: used in the SharedFields.tax_type.choices, removed the underscore here as well.

I've been hesitating between keeping the semantic difference with None/NULL meaning that no tax applies, but after thinking about it some more I can't really argue for it:

Will it make querying for tax reports easier? not really, even though indexing a decimal won't make much sense, the queries will most likely use tax type and tax country, not tax rate.

Does it make sense from the legal standpoint, e.g. to a donation 0% tax applies, but tax does not apply when selling to US? Not sure, but then again you are probably right and we won't be using this semantics.

Will get rid of the Optional[] and always return a Decimal here.

I guess you meant ProductType, right?
(moved it into the class)

At this point we assume that buyer_country_code is a valid country code (it was validated elsewhere, e.g. in the form), and vat_rules being false-y means that there's no applicable VAT-rule.

Doesn't work well here, in my opinion, because of the nested condition: adds at least one identical return Decimal(0) statement

If Optional is removed this error is raised:

ValueError: No mandatory attributes allowed after an attribute with a default value or factory. Attribute in question: Attribute(name='tax',...

attr doesn't allow to initialise the Taxable without some value of tax, not sure there's a way to have tax: Money given that Money has to be passed the a currency value (Money(0) is not a possible value).

Added Taxable.price_with_tax which stores the unchaged price, this way there's no need to change any code in blender-studio (and obvious naming seems to help too).

Also, after trying to figure out how to get rid of Option[Money] for price and tax, which are only Optional because these attributes are calculated after the __init__ and Money cannot have a default value without currency, turned both into @propertys.
This seems to make more sense overall: makes typing more correct and makes it obvious that these values are calculated.

Nice solution!