When it comes to performance, @inline(__always) and @_specialize should not be needed anymore. @inlinable should cover any performance‐related uses of either of them. And if it doesn’t, that fact should be reported as a bug.
If @inline(__always) is being used for security reasons—which it isn’t reliable for in the first place—then you really do not want it to go ignored and open a security hole.
If @_exported is being used, demoting it from error to warning won’t solve anything, since with the re‐export missing, you’ll hit a sudden wall of undefined symbol errors.
Their use cases are not too narrow. As noted above, @inline(__always), @_specialize and their relatives already led to the fully supported @inlinable. And the problem space of @_exported is undergoing active development to transform it into a more robust model that can be declared stable:
They are doing so intentionally. Those attributes are not in any official documentation. If a developer even knows about them, they either discovered them as experimental features buried in the compiler’s source code, or received them as a suggestion from someone else who had. When these attributes pop up in conversation around here, it is always with a disclaimer that they are not finished yet and are a use‐at‐your‐own‐risk sort of thing. And for the most part that is true of the rest of the web as well.