Not clear why this must be. In some respects, taking C++, for example, if your function naming style is different from the standard library there is a visual way to distinguish between builtins and project defined code. Personally, I like namespaces to make this distinction, but a different naming convention does not hurt.
For things like where to the braces go, how many spaces for indentation, and so on, it completely does not matter because you don’t see this part of the library - your interaction with the library is via the API.
One argument for this might be that you want to contribute to the standard library and it’s easier to match their style if you already code in it, but I suspect this is a minor aspect.
Hm, there’s quite a couple of languages where development style has vastly diverged from the stdlib of the language.
Sure, when it comes to things like class and method casing, you should probably stick with what std does. But for anything that happens in implementations, style is constantly evolving and the stdlib is - most of the time - the oldest piece of code around, predating all this time.
I think the best style is the one that works for you and your team. It’s always going to be somewhat subjective, perhaps with a few nuggets of objectivity here and there.
Language standard libraries come in good and bad varieties like any other library. It’s absolutely worth finding a wider community/ecosystem that has a style you can participate in, and deviating from the consensus comes with a cost - for choices that are arbitrary or close to it, it’s worth going with what the community has standardized on, because consistency is valuable. But that community consensus does not have to be the standard library one - the big languages are popular enough to sustain multiple communities with their own ways of doing things, and while it’s worth knowing which one you’re in, the standard library one will not olways be the best one - and sometimes the consensus position is bad enough to be worth the cost of deviating from.