For several reasons:

• Its internal design fits more with what API Platform needs internally (chain pattern instead of visitor)
• The Symfony Serializer benefits from the release policy, Backward Compatibility promise and time-based releases of Symfony
• 2 people of the API Platform Core Team are also proud members of the Symfony Core Team (including me). It means that we're never "blocked", we can merge the features and fixes we need easily in the Symfony Serializer
• JMSSerializer has been unmaintained in the past (it's not the case anymore), and it would have been a huge issue for API Platform. The truck factor for the Symfony Serializer is currently better
• And the main historical reason: when API Platform has been started, JMS Serializer was licensed under Apache v2. This license wasn't in sync with API Platform's goals because it isn't compatible with GPLv2 (used by ezPublish, Drupal, phpBB...). The license of JMSSerializer v2 changed recently to MIT (same as Symfony), so it isn't an issue anymore

And according to the latest benchmarks, Symfony Serializer is faster, but that's not very interesting because both are very fast anyway.
Regarding features, the Symfony one has features not available in JMS Serializer (YAML and CSV support, type checking, smart property access - most of them have been contributed for API Platform actually) while JMS Serializer also has some features still lacking in the Symfony one (nicer annotations-based high level config).

To learn more about the Symfony Serializer, how it works and all its features: https://dunglas.fr/2018/05/mastering-the-symfony-serializer-php-tour-slides/

@dunglas , thanks for you very detail explanation.

@dunglas you should enable to possibility to chose the serializer we want in the configuration the same way it is done in the fos rest bundle.
My existing entities were using the jms annotations such as groups, expose, MaxDepth etc
Now that my project is using API Platform I have change my annotations from JMS to Symfony Serializer which is lot of work to do

@babacargithub Sorry, while what you suggest sounds nice on paper, it's not feasible. We're not going to do it. This will not change in the foreseeable future.