Why SMO's Transfer tries to login into linked server when scripting?
You can only get data from a SQL Server that you are logged into.  The metadata of table definitions, stored procedures, and so forth is also data.

So, your login through the linked server must be successful.  This can be done by granting your login rights on the other server.  Or, the security of the linked server could be through a specific login that has the needed rights.

However, getting rights to the metadata of a database does not imply that you need rights to the data in the database.  For example:

USE DBName;
GRANT VIEW DEFINITION ON DATABASE::DBName TO [YourDomain\YourLogin]


This will allow you to script the definitions from the database without having access to the user data.  (Although that can also be granted separately if needed.)

EDIT: SQL Server does not support deferred name resolution across a linked server.  Therefore, I am fairly sure that since the reference to the remote table cannot be resolved that is why the scripting is failing.

Of course, if the stored procedure is not encrypted then the text is stored in sys.sql_modules of your local server.  You could extract the text from there.

 SELECT definition FROM DBName.sys.sql_modules 
 WHERE object_id = object_id(N'DBName.Schema.ObjectName');