it's not specifically intended, but it's just a direct consequence of
when SpatiaLite is called by the SQLite's own SQL engine to process
ST_Transform() it simply receives two arguments:
1. the BLOB geometry to be transformed
2. the intended destination SRID
as you can easily see, there is absolutely nothing specifying if
the BLOB-Geometry initially was a GPKG geometry or whatever else;
when ST_Tranforms() receives the BLOB it has just become a SpatiaLite
native geometry as any other, and there is absolutely nothing
that can suggest it's real ancestry.
all this considered, it's now obvious why SpatiaLite can't
look for "gpkg_spatial_ref_sys" and friends; it's because
we haven't the slighest clue that it initially was a GPKG
a more general consideration: SpatiaLite is not a tool
intended to fully support GPKS.
it simply is a library mainly intended for implementing
SpatiaLite itself; whenever is possible it will make any
honest effort to support GPKG as well, but it's more
a byproduct than the main design goal.