I would suggest you avoid procedures that are documented as being "legacy" when working with new databases.
Cross-database queries in SQL-Server are inefficient, and should be avoided as general practice, but if you really want to create such a view, the table should have a native geometry type (GEOMETRY or GEOGRAPHY). Then all you need to do is register the view with ArcSDE using
sdelayer -o register. You will need to make sure a NOT NULL integer (32-bit) column with non-zero, positive, unique and reproducible values exists and can be registered as a USER-set rowid.
You can't use SDEBINARY geometry cross-database in modern ArcSDE instances. But you can create a phantom table (or tables) with the same columns in the same database, create a view on that (them) using
sdetable -o create_view (there isn't much room for cleverness in syntax, so don't bother, but all columns should be present as the same datatype they will become in the modified view), then use SQL-Server tools to edit the view to be as complex as you like. Note that this is not supported, but it works and is as reliable as any hack ever is.
Oracle did not even have the possibility of cross-database operation because it only introduced multi-database architecture at Oracle 12c. Esri does not yet support that capability with 10.2.2 (the first release to support 12c), so the point is moot. Colleagues of mine have used "database links" to submit queries across database instances, but this solution is generally fiendishly inefficient, and requires extensive tuning.