Th part of an URI after the # is called "fragment" and is by definition only available/processed on client side (see https://en.wikipedia.org/wiki/Fragment_identifier).

The main problem is that the browser won't even send a request with a fragment part. The fragment part is resolved right there in the browser. So it's reachable through JavaScript.

The simple problem that I see with fragment identifiers is that their existence and functionality relies completely on the developer rather than the browser. Yes, the browser needs to read and interpret the identifier and identify the matching fragment. But if the developer doesn’t include any id attributes in the HTML of the page, then there will be no identifiable fragments. Do you see why this is a problem? Whether the developer has coded identifiers into the HTML has nothing to do with whether or not the page actually has fragments. Virtually every web page has fragments. In fact, sectioning content as defined in the HTML5 spec implies as much. Every element on the page that can contain content can theoretically be categorized as a “fragment”.

This means that, regardless of what the developer has done behind the scenes in the HTML, all HTML fragments on that page should be identifiable by external referrers.

There is a fundamental weakness in the name attribute, which the id attribute addresses: the name attribute is not required to be unique. This is OK for forms where you can have multiple elements with the same name, but unsuitable for the rest of the document where you are trying to uniquely identify an element.

HTML fragment identifiers, as defined in the registration for the text/html media type [RFC2854] operate on id attributes and (now less frequently) the name attribute of the a, applet, frame, iframe, img and map elements.