If these fit all the concepts you want to model, then yes. But e.g. for Issue Management and other areas I think it quickly makes sense to define your own - to-be-standardized - extension for it. Do you want to map a Ticket Comment as an as:Note? Maybe, but it is entirely non-descriptive. Maybe an as:Note with addditional properties? Then you already have your extension format right there.
That federated search could build their own AP server from scratch, but since there’s already FP platform with plugin support, they might as well decide to save this work and just write a plugin for that, which comes with its own UI (either on the FP instance, or a separate webserver with a custom API).
All in all there are many different use cases that can be brainstormed, but on the whole you want to avoid restraining the solution you offer unnecessarily. Many use cases will come from unexpected corners by people who see an opportunity. The potential cost/benefit ratio of offering additional extensiblity and flexibility may be well-worthy of the effort to create the architecture that facilitates it.
Yea, I see them as ‘lego blocks’ (where blocks are what we currently think of as ‘apps’). By putting blocks together you get the actual thing you want, and the blocks themself are not foremost in your mind when looking at the end result.
I’ve described this a bit in From silo-first to task-oriented federated app design. The apps become sorta ‘irrelevant’, existing on a lower architectural level and instead you focus on the tasks / processes / things you want to achieve with them.