Instance and database (Oracle vs SQL Server)
I'm a DBA on Oracle and SQL Server.

The confusion is due to a mismatch of semantic and an extra level in SQL Server's hierarchy but there's more than that!

Note that we will talk only about single instance database in both instances (pun intended).

Instances

In Oracle, one instance will have an amount of memory allocated to it (SGA/PGA) and processes spawned (smon,pmon dw0X and so on). There are system views to monitor all of the stuff that will be created and used (V$ and dba_ views).

This is the structure we are familiar with in oracle.

And you already mentioned it, the database is where the physical files are. Typically moving to RAC makes the difference glaring.

In SQL Server, the instance works the same way:
A bunch of memory is allocated and there are system views (sys.) to monitor all of that stuff. 

The instance has 4 system databases:


system where the system views are.
msdb database which also holds system related information. Typically that's where you will find your backups related data. A bit of maintenance is required on it at least to flush old backups records.
model, the aptly named database which is used as a model for every new database you will create. It's a good idea to modify the data file settings (auto extend, initial size, backup mode) so all new database benefit from it.
tempdb developed below.


The system database holds meta data information for every other database on SQL Server.

Temp space

In Oracle:

Temp tablespace (create temporary tablespace).
In oracle the temp tablespace is a spill zone for operations which can't fit in the PGA (process memory, default at 200M (up to 11g), your hash join for example if bigger than 200M spills in temp tablespace, generally that's a cause of slow performing query).

In SQL Server, there is a tempdb database located in the "system databases" section and it's very actively used, much more than in oracle. Place it on very fast disks (SSD or fiber comes to mind)

Thus comes the 2nd large difference:

Objects

In SQL Server:

The objects (table,views), are not tied to a user as in oracle, but rather to a "database".
The "database" holds (not own), the objects. At the creation time of the database, a data file is mentioned to store these objects.

In oracle: 

A user creates objects which will land in a schema of the same name. Naming the users carefully becomes important.

And here comes the 3rd big difference:

Security

In oracle:

Users will be created and they will be given the right at the very least to create sessions so they can access objects they have been allowed to.
Or, they will have the right to create objects in their own schema (resource role), which will then create a schema in that name.

You may chose, and it's a good practice, to create a tablespace and make it the  default for each users able to create objects. If that's not done, a default tablespace is used, generally "USER_DATA".

In SQL Server:

Since the objects are not owned by a particular user in a schema, users must be first created, then privilege assigned. Typically, whoever will be the main user to do the object creation will be granted the "owner" role on a given database. 

That user in SQL Server would be the equivalent in oracle of a schema owner but there may be more than one owner.

Security is where SQL Server shines over Oracle: SQL Server security can be tied to Active Directory which manages the desktop users. These desktop users can be tied to a user group say "read only". It's possible to add that active directory group to SQL Server and give it a "read only" access to your database.

When a user leaves your company, the Active Directory Admin delete that user and access to the database is lost as well.

Oracle can use LDAP but let's face, it's not very often well tied to the windows desktop users.

The 4th big difference.

Semantic

SQL Server has an extra layer. In a SQL Server database, objects may be organized in schemas. Schemas may have owners too. It introduces more fine grain security as well but while it's used, it's not common. I would say it's also good practice to group your objects by schema early in the development stage to benefit later on from extra security abilities when needed.

Logs / Archived Logs

Finally archived logs work differently in oracle and SQL Server.
SQL Server has a log file created for each database, while oracle has archive log mode turned on at the instance level.

This is where the line blurs. For some aspects, SQL Server's databases really are databases. In other instances they look more like schemas.

The archiving in SQL server is set with the option backup mode set to full. Then they are archived by performing a log backup. The log backup will require a full backup to take place before it starts working.

In Oracle, archived logs are archived automatically, then we back them up to a remote location.

Summary

Oracle:

Instance-&gt;User1-&gt;Schema1(named User1)-&gt;Tablespace1
                                     -&gt;Tablespace2
        -&gt;User2-&gt;Schema2(named User2)-&gt;Tablespace3
        -&gt;User3-&gt;Granted "read only"-&gt;schema2.table1


SQL Server:

Instance-&gt;Database1-&gt;Schema1
        -&gt;Database2-&gt;Schema2
        -&gt;User1
        -&gt;User2

        -&gt;User1-&gt;Granted "owner"-&gt;Database1
        -&gt;User2-&gt;Granted "read only"-&gt;Database2-&gt;Schema2


These are the things that come to my mind when I get to compare both.
I would love to hear more from others and add on/correct this answer.

Also I don't have a particular preference for either. 
I think they both do a great job and I enjoy working with both very much.