But I feel like this is not precisely the same concept. In Selenium tests, the Page Object quite literally represents an entire HTML page. In the Angular 2 docs, it only represents a single component that would be used on a page.
What are the tradeoffs behind naming something based on a historical concept that the thing is drawn from vs. naming it based more exactly on the current concept? I can see where naming it "Page" would make it more accessible to people who had previously worked in Selenium, but it seems like it might be harder for new people to understand it as a Page when it's not really a Page.
Edit based on feedback
I think that there are often cases where something could be named according to a legacy convention or using a fresh name that more exactly matches the way the concept will be used moving forward, so I don't think that there's that big a need for background information in an answer.
I've actually been on a project where I rewrote an older framework and tried to keep concepts and variables as close to the older framework as possible to make it accessible to the people who had worked on that framework previously. But it was several years before anyone from that team used the newer framework and they worked on different projects than I did so I didn't get much feedback on whether that helped them. In this case, there may or may not be overlap between people familiar with the Page concept and most Angular 2 developers.
Assume that this is based on someone starting a new Angular 2 project that may add developers later. The future maintainers may not have Selenium experience, and the original developer is trying to decide whether to follow the "Page" convention from the documentation or call it something more close to the actual concept, like "Component," or even "ComponentPage," to pay homage to the older pattern while updating it.
What factors would come into play in deciding whether to just straight up follow the current docs vs. striking out in a way that makes more sense in isolation? I feel like I'm probably not the only person who's ever going to notice this, so there's a possibility that the docs could be updated if the "right" person points it out. OTOH there's a lot of counterintuitive stuff in popular Angular style guides that don't make sense in really large projects IMO so that might not be a large risk.