Found the reason for this "caching".
IIS runs extensibility components in a COM+ application called "Microsoft FTP Publishing Service Extensibility Host". Once the extension is loaded, the assembly is loaded into corresponding process (hosted by dllhost.exe) and thus is not immediately affected by any GAC changes.
Working solution (covers a bit more elements than the scope of the original question):
FTP service is configured to load my extension component written using .NET 3.5 - because it ONLY accepts .NET 2.0 runtime; if you implement extension in runtime 4 it simply won't run
extension component, in its turn, needs large codebase that is implemented using .NET 4.5 - and it does so via COM (those APIs are registered in COM, but not in GAC)
when I recompile the FTP service extension, it is enough to update GAC and shutdown the "Microsoft FTP Publishing Service Extensibility Host" COM+ application and, preferably, FTP service too.
Now I do not have to change the strong name (by changing version number) of the FTP service extension assembly for every change.