We had a number of problems with ld-signatures, which at one time was a required component of the emerging activitypub protocol. One of these is that LD contexts can change, rendering signatures invalid. We actually use content signatures for third-party relaying of restricted content that can't be fetched directly by the third party. Think private groups. It's an important component of our architecture. In our other protocols we use much more reliable signature methods which don't have multiple single points of failure.
This work was done before Mastodon had a working ActivityPub implementation. They were still using OStatus. When Eugen started adopting ActivityPub I brushed off what I had already done and tried to federate with his test site. Eugen refused to collaborate with anybody for his own development, so I was forced to make things up as I went. There were no other ActivityPub sites at the time, period. We didn't have any other implementations to compare against or federate with, and ld-signatures were always a hot mess that barely worked. Our applications are nomadic and sites come and go. There is no "flagship instance". We take decentralisation very seriously. Every instance is permitted to install additional addons and the context provided by core might not be valid for other instances of the software. We can't even trust the core context providers to maintain a document at a particular location, as we found later with the core security contexts. So each instance provides their own context and we cache them. LD-signatures or any other LD processing requires you to support external contexts that you may not have ever seen before, and you absolutely need to cache them for as long as you expect your signatures need to validate.
I left Hubzilla after the whole Mastodon/ActivityPub fiasco and went on to do other things. I no longer agree with or implement things in the same ways. I still collaborate a bit with the Hubzilla folks, but I don't tell them how to do things. It's their project now. And it's all open source. If you have a problem with any executive decisions I made when there were zero federating ActivityPub implementations, please just file a pull request.
As for the keyid, if you fetch the keyid, you're fetching the actor document. It's the same bloody document. The webserver doesn't see fragments. Why does it need a different id? Again, this decision was revisited in later work, but now I use query arguments instead of fragments, because once again the webserver never sees the fragment. From the webserver point of view it's the same document and is retrieved with the same exact url. The fragment is an imaginary thing that was added to make the ids appear different even though they are not. It has no other purpose. And even my query arguments serve no other purpose, because when sites request the keyid, they really expect an actor document, not a publicKey document. I think a number of fediverse softwares would crash if they actually got a publicKey document. We also use http-signatures with keyIds for OpenWebAuth and these conflicted with ActivityPub keyIds at one time. This was also fixed in later work.
This is all water under the bridge. But if you want to know "why" I did these particular things 6-7 years ago, this is why.