Sql-server – User mapping to a standby database

why are those operations on the log file if they haven't been committed in the first place

All operations, committed or uncommitted, are written in the log. A commit ensures that all log entries are made durable (flushed to disk), but nothing prevents uncommitted entries from being flushed before that (either because a log block fills or because another transaction commits, thus forcing the flush for every transaction). A rollback must analyze all the transaction entries and generate compensating actions (for every insert do a delete, for every delete do an insert, for every update do an update that reverses the data back). These compensating actions are, of course, logged.

When a database is recovered it must rollback any transaction that is not committed in the log. It must as such analyze the log, figure out the uncommitted transactions, and then generate compensating actions for any all actions belonging to uncommitted transactions. Online recovery will write the compensation actions into the log itself. Standby recovery will write the compensating actions into an alternative stream, thus allowing for further log to be applied form a 'master' source later (this how log shipping standby read only access works).

Before asking any clarification question, please read ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging.

editted based on feedback in comments

1. If you could stay readonly than a good alternative to replication could be log shipping. The vendor would create transaction log backups. And send those backup to you. You then apply those backups.You can't restore differential only, you would still need to reply a full first. Another benefit of (delayed) logshipping is that, since the source is at the vendor (where you have no control over what they do with it, you might want to build in some buffer (in time) that when they make a huge mistake, you simply pause the logshipping redo, so you still have a good copy)
2. For restoring filegroups/files you need transaction log restores as well. It can work but it highly depends on the growth rate vs the transaction log rate if I would prefer this above option 1, simply log shipping. Furhtermore, partitioning your database and table just for the sole purpose of solving your replica problem wouldn't be the route I would pick first but I have some questions for you later.
3. Replication sounds like a very good option if you think the restoring of transaction log backups becomes to much work.
4. What prohibits sql 2000 from doing Bulk Inserts? However, if you think logshipping is tedious, keeping track of updating every single object sounds like a potentially more troublesome strategy.
5. I have no experience with cdc. somebody else has to help out on that.

Couple of questions for you:

1. How big is the initial database size?
2. What will be the daily, monthly growth rate?
3. What will be the daily growth rate of the transaction log?
4. is it possible to have both locations in the same domain?
5. Is it possible to build a secure connection between the two locations?
6. What is the bandwidth between the to locations? what is the latency?

If we have some numbers, it's easier to provide you with a better advise.