protected helps a lot during refactoring to safely remove unused code or rename some variables, methods, change their signatures.

If I challenge just the idea of pushing protected: I never had a case where I have to inherit components. Also had some feedbacks of devs saying to avoid inheritance when you migrate Angular. Then I guess people just go with the least effort solution and leave the default visibility (public) for components properties.

But my inner strict persona would say "follow the rule of: use the minimum visibility possible private < protected < public". If my code still works with protected visibility, then I should use it, but if it works with private visibility, then I should use private.

And on the side note, services are not "template properties" and for services I could see cases where inheritance make more sens. And also you can't use a service function if it's protected :)

It is not related to inheritance at all. I also never extend components.

The new style guide has a dedicated entry about this : https://next.angular.dev/style-guide#use-protected-on-class-members-that-are-only-used-by-a-components-template

The idea behind this recomendation is that component properties that are only meant to be uses in the templates, should not be exposed as part of the public API of the component. This is why Angular templates have acces to protected properties.

@JeanMeche thank you for the link I missed that one. But then I think I find an issue because outputs seems to work with protected but not inputs, do you know a reason why? (e.g. stackblitz to show the issue, we log the output from parent component https://stackblitz.com/edit/stackblitz-starters-4xt6l5f4?file=src%2Fmain.ts)

Uh that's a good find, It should be consistent imho (as in we probably should support protected outputs).

outputs are part of public API by definition.