i think using DIDs to define the context for DIDs would be a circular definition, no? 
this just has to do with json-ld processing. if you provide a string value in the @context then it is coerced into an @id (and then fetched and inlined into the document for processing). meaning you can type https://www.w3.org/ns/activitystreams and the json-ld processor will do an HTTP GET with the ld+json Accept type, and include whatever is served from there. it has nothing to do with an individual term – any term can be defined as any IRI, and IRIs include URNs.
well, you would want to adopt mastodon’s https://joinmastodon.org/ns# (it doesn’t matter what you call it) only if you cared about compatibility with mastodon and/or found its definitions useful. consider the case where the DID Core terms adopted alsoKnownAs from activitystreams – DID Core v1.0 Terms shows that the DID @context includes the security and activitystreams vocabs as well, and the only term adopted from activitystreams is https://www.w3.org/ns/activitystreams#alsoKnownAs. if you really cared to formalize some prior term, you could adopt it in the same way… but do you have the authority to (re)define it?
the problem with relying on mastodon’s namespace and terms is that you are bound to their expectations. for example, if you wanted to use featured for your concept of a “featured” collection, do you include only “posts” or do you also include “hashtags”? mastodon defines a separate featuredTags collection currently, but they might unify the two properties at some point and even integrate the concept of “featured accounts” into the same featured collection. or they might do something completely different. who knows? you’ll have to deal with that uncertainty that mastodon might change the meaning at any time.
luckily, there’s not actually much in there that you “need”. mastodon has been somewhat careful in adopting existing vocabularies where possible. maybe even too careful – the “profile fields” feature depends on an (incorrectly mapped) term from the schema vocab, and it could have been implemented using native activitystreams terms. see FEP-fb2a: Actor metadata for more details.
mostly, you might care about adopting Emoji for custom emoji, or blurhash for more colorful placeholders, or focalPoint for centering part of an image when using cover-fit. maybe you want suspended for marking an account as locked by moderators. everything else could possibly be better defined by some other vocabulary or FEP:
discoverablecould be replaced by a fuller-defined set of flags indicating consent for various data representations and usages. (as it stands, this property is currently only used for the somewhat-defunct “profile directory” feature and also for the “trending posts” feature.)votersCountis dependent on implementing polls in the same way as mastodon. (i’d honestly recommend or possibly take on myself a more “proper” definition of what polls should look like – theas:Questiontype as currently (ab)used is not really fit for this. but then again, it was based on a non-normative section…)featuredandfeaturedTagshave the problems described above (their contents are unspecified and their definition is quite mastodon-specific)IdentityProofis no longer used but i suspect there’s a better term or really a better way to express this use-case – probably DID verification methods, but i’m not 100% familiar with how those work
i’m not entirely sure of the whole landscape and which implementations have defined which terms and how many of those definitions are actually relevant (given that some implementers are “plain JSON” and not “LD-aware”), but i suspect a non-negligible number of extension properties can be formalized in an FEP or some other recommendation/proposal. it would have to be evaluated on a case-by-case basis.