I have read in some questions this is absurd. What is wrong with these code snippets?

Nothing. I do not know what is so absurd about the answers you are reading.

The only thing this decoration does is force the XML serializer to use the given values, instead of using the string representation of the value of enum .

Counters

An enumeration is a sequence of constants. In general constants must have their state immutable throughout the project lifecycle (the answers in that question give the details) . Eventually you can add something new at the end, but no more than that, even though it does not always work well, even though it's very well documented.

If a data can be modified, even though between versions of the application ideally it is not constant, it is rather than just be immutable .

π (Pi) is a constant. A code that depends on legislation is not a constant. It is a data that at most does not change during the execution of the application, but not during the entire project life cycle, it is not constant.

Data that is not constant is already problematic when treated as if it were. It gets more complicated when these constants are in sequence. It's harder to guarantee status.

Enumerations are programming mechanisms. No compilation engines. They are not meant to validate business rules.

This example takes parameters and transforms them into constants. Big mistake.

There's another question about abuse of enum in database .

Data control

So an enumeration has to be something you have control of, that you know will not change.

What kind of person is legal or physical is your inner self? Can you guarantee it's always this? Does it affect anything external? So no problem doing it.

Or is it something defined by legislation? There are no guarantees that the legislation will not change? If you do not have control, do not opt for something constant. Do something that explicitly states you can change. Use a data structure conducive to change. Even though it never changes, this will be a fluke, the semantics of the data is that it can be changed, so represent it appropriately.

The same goes for Item11 . It has no context whatsoever, but it seems to be something that depends on legislation (the question is out of context, a lot of people will not understand that the original speaks in NFe ( has a worse case ).

The best explanation for this is the ID that everyone uses in the database. Why do you use a ID and not the person's CPF, for example? Because nothing guarantees that this person will not go to exchange the CPF. You create a surrogate given to refer to that. You do not use the CPF because you have no control over it. The same goes for a vendor product code, email, or the like.

Changes

If you change and your application was made thinking that these data are constant it will be a nightmare to maintain it. A little change in legislation (and there has been a change that has changed everything ) can cause the whole system to stop working, and to fix it, you have to redo it.

It may be worse, a change goes unnoticed. It may appear to be working but it is generating the wrong result. Imagine an exchange of order. When data can change you need to have a canonical reference of it within your system that does not depend on external information.

Make the system ready for change.

Correct concept

People need to understand which systems do not just have to "work". They need to be conceptually certain to support future maintenance. If a data is part of a changeable table, represent it as a changeable table. Choose a dictionary or another data structure best suited for this. You can even create your own structure if it is beneficial. But do not use a constant structure.

Note that these dictionaries will possibly be populated with data coming from the database. Or even the database will be used to provide what you need directly.

Using [System.Xml.Serialization.XmlEnumAttribute("11")] already shows that it is the wrong mechanism. The actual data is text. An enumeration does not represent texts, it represents numbers. This is an attempt to fix the initial error. And it's one more mistake. Hence we conclude that errors attract errors. It only gets worse.

I have not even talked about the code readability . Do you think an enumeration called TNFeInfNFeDetImpostoICMSICMS00CST is for anything in the code? Can anyone tell you what it's all about without fear of making a mistake?