Since #14050 ChoiceType has a choice_value option to dynamically set the option value as a callable or a PropertyPath.

EntityType since inherited this option but its implementation defines a value based on the database id by default.

While choice_label replaces the deprecated property option and choice_attr is working well with EntityType, here's an example in a recent question on stack overflow :
http://stackoverflow.com/questions/35085983/access-properties-and-methods-of-a-class-while-configuring-entitytype-in-formbui/35097053#35097053

(As a matter of fact choice_attr and choice_value are not mentioned in the doc of EntityType as of 2.7 but I will very soon open an issue in symfony-docs for it and other suggestions)

That said, the real point of this issue is that nothing prevents to use choice_value with EntityType when its actual implementation seems to enforce using id as value.

But defining choice_value is actually working and renders the form view as expected.

The problem is it cannot be validated since submitting the customised choice value will not match any id in the transformation process and an error is mapped to the field saying "This value is not valid".

Two ways to solve it IMO :

1/ Define choice_value as unavailable in EntityType both in the doc (2.7) and in the class by a normalizer :

// Symfony\Bridge\Doctrine\Form\Type\EntityType::configureOptions()
// ...
$choiceValueNormalizer = function (Options $options) {
    return null;
};

$resolver->setNormalizer('choice_value', $choiceValueNormalizer);
// ...

But that would make me sad so let's talk about :

2/ Let developers use choice_value in EntityType as it's very close to work like in ChoiceType, and of courses, update the doc.

For this, there's only need to check if choice_value is null in DoctrineChoiceLoader.

PR on its way !