You certainly could do this but if revision control is what your after for documents use something like subversion or git. In general storing documents that do not depend on transactions and you are not storing sensitive information that requires immediate atomicy and consitency like financial transactions then a nosql solution may fit your needs and be appropriate.
To the best of my knowledge you'd have to be rolling your own in the revision diffs if that's something you're really looking for whether from a nosql or traditional sql solution.
Regardless, if you're working on something trivial and want to play around with newer technologies that you're unfamiliar with that's great, go for it.
At the same time, if this is for a commercial client and you aren't familiar with mongo, couch, etc it's probabaly better to stick with what you know and leave the sandbox for play time until you're ready.
Oracle is a SQL DBMS not a truly relational database. It implements as its logical model of data a variant of SQL. Its architecture was developed in the late 1970s along the same lines as IBM's System R which was an initial implementation of a DBMS based on the relational model using SQL as the data sub-language. This short background is necessary to understand that SQL and Oracle are not the same as relational. The relational model, as defined by Codd and further developed by researchers like Date, is a purely logical model of data where data is to be presented as relations, with a relational algebra defined to manipulate the relations, and a data integrity component to make it possible for the DBMS to maintain data consistent with its real world intent. The relational model is mute on implementation by the DBMS. Therefore, when identifying a use-case that a given SQL DBMS does not handle well purely due to performance reasons, the issue lies with the implementation, not the relational model.
Given this, I suspect NoSQL solutions are sometimes recommended over SQL DBMS' for time series analysis as time series analysis is a very narrow use case and the SQL DBMS architecture was aimed at more generalized online transaction processing use cases. I know little about time series analysis but do recognize that it is purely analytical and not OLTP, and so transaction support - which is a mainstay of SQL DBMS' but orthogonal to the relational model - is pure overhead in such a use case. I recall seeing Michael Stonebraker a few years ago discuss time series analysis and argue the solution was to store data in arrays not rows. Since all the SQL DBMS's are row-stores, that may be another reason why other solutions are recommended.
I would caution against diving right into a NoSQL solution. These systems are much less mature than traditional DBMS'. Secondly, time series analysis I believe is pretty heavy statistics and you will likely have to add that yourself with a NoSQL solution. A mature SQL DBMS like Oracle may have some built in statistical features that are much easier to use. Third, SQL is, despite its flaws, a complete query language giving you the power to write queries of arbitrary complexity. Most NoSQL solutions require you to write programs to perform the analysis you want. Finally, and perhaps most importantly, it is likely that to get any useful information out of your time series data you need to "enrich" it with other related data. For example, I work for an electric utility and in this business just having a huge amount of time series data on how much power was used for an interval of time isn't very useful unless you can correlate it to weather, demographics, and so on. A SQL DBMS, precisely because it is a generalized data management solution, makes that easy. You can place the time series data in the same database as the enriching data and have the full power of SQL to join and analyze it. With a NoSQL solution you will have to perform the enrichment yourself as an additional step - potentially extracting, transforming, and loading the data from the very SQL DBMS that wasn't used to store the time series data in the first place! It will be a lot of extra work to write the ETL programs, and you have to decide at the time you write them what data will be useful for analysis. If later you decide you didn't have everything useful, you now have to write more programs. If instead you placed the time series data in Oracle right along with all your other data it is already in place and ready for analysis once you discover a need.
Bottom line I would say that unless can prove you have so much data coming in so fast as to exceed the capacity of your existing SQL DBMS installation, and you have the time and the skill sets necessary to write the additional infrastructure on top of a NoSQL solution (assuming of course the NoSQL solution you choose does have the capability to scale to the data volume and velocity), you are better off sticking with the SQL DBMS.
Best Answer
Typically No-SQL solutions were implemented due to massive scale and not needing 100% ACID compliance. Flattening data out and de-normalizing it for performance gains were critical in getting us to where we are today with solutions such as GFS, Hadoop, Mongo, Basho RIAK, etc.
Your case doesn't scream No-SQL, if anything you'd probably be better served with MS SQL server since you're using the ASP.NET stack and MS SQL Server provides a lot of functionality with ASP.NET through CLR, powershell (which can also call .Net objects) and playing very nice with IIS (I assume you'll also be hosting it on IIS). This also sounds like something you can use SQL Server 2012 Express thus saving licensing costs.
MS SQL Server will also let you easily 'join' data across non related tables in cases where you come up with a new idea, and on a No-SQL solution that would be more difficult to implement.
But in reality, looking at your requirements and what you're going to be using it for. You can go either way. If it makes you happier to use a No-SQL solution and get your feet wet, awesome! Go for it! End result probably won't matter, but to strictly answer the question, which is better for a .Net app with the usage patterns you described, I'd personally go with SQL 2012 Express.
I'm curious to see what others think!