This is a run down of things to be aware of if you are trying to edit attribute data stored in ArcSDE via Multi-Version Views.

I'm writing this up because the ESRI documentation on using multi-version views is rather lean, particularly with respect to managing ObjectID's and dealing with versions after you've made your updates.

Editing Data Via Multi-Version Views
Multi-version views can be used to edit attribute data stored in ArcSDE via SQL statements, but some very specific conditions must exist for this to occur. The most important condition being that when doing inserts (creating new records, which will lack a spatial representation), the multi-version view can not be referencing a version currently in use by ArcMap. This is explicitly stated in the Multi-Version View documentation.

While no explanation is given, my investigation leads me to believe that this is related to the fact that ArcSDE controls the value of the ObjectID column, but that inserts through the multi-version view's do not automatically utilize this functionality. Rather, the developer must manage the ObjectIDs. The easiest way to deal with this is to use SQL and get MAX(ObjectID) from the multi-version view , and add 1. However, if there is an ArcMap session that is also editing this same layer in the same version, this scheme does not work. This is because ArcMap "checks out" a block of ObjectIDs as soon as an edit occurs on a feature in a particular feature class. (This is what those i[reg#]_get_ids stored procedure is for).

Thus, if edits are occurring in ArcMap, and an multi-version view is used to insert a record, assigning ObjectID to MAX(ObjectID) +1, this feature will be in conflict with any newly added features that are created in the ArcMap editing session.

Overcoming ObjectID Issues
After some digging around, I believe that you can use the i[reg#]_get_ids and i[reg#]_return_ids stored procedures to "check out" a block of ObjectID's just like ArcSDE does. I say "believe" because the application I'm building does not require this because of it's business process (inserts go into another set of tables, which are never loaded into ArcMap or anyother ArcSDE client - thus Max(ObjectID) + 1 works just fine. Anyhow, as long as you "get" a block of ID's (I'd suggest 1 at a time so that you avoid having to "return" them) you should be able to insert records.

Named Versions
Another wrinkle, which is noted in the documentation, is that you can not make edits into a version currently in use by ArcGIS. If you try to run an UPDATE or INSERT query against the MVV while the version is open in ArcMap, an error is returned. If you run the query in SQL Analyzer, you'll get something like this:

Server: Msg 2627, Level 14, State 2, Procedure SDE_state_def_insert, Line 21 Violation of UNIQUE KEY constraint 'states_uk'. Cannot insert duplicate key in object 'SDE_states'. The statement has been terminated.

Thus, if there is any chance that there may be an edit session underway, you will need to create a named version and run the queries against that version. This works as shown in the documentation - just make a call to the sde.CREATE_VERSION stored procedure. What the documentation leaves out is how to then post & reconcile this named version back into the version that you actually wanted to work with!

While there are not stored procedures that can deal with this, the developer kit has is a sample which can help out with this part - check out the "Versioning Service" sample.
Essentially, you need to use some ArcObjects code to actually post and reconcile the newly created version. Again, this can be pretty simple, but if there are edits occuring in ArcMap, then there is a chance you will have conflicts, which leads to the question of how to resolve them. For my application, this is not a real problem the data being added via the multi-version view's is field data, and thus more correct than anything that would result from ArcMap edits. Additionally, the user who is adding this data into the system is the only user who actually has edit permission to the features that would be effected. (maybe I'll cook up a post on feature level security...) Anyhow, if a conflict occurs, the data from the multi-version view version always overwrites the other data.. However, this is just another fluke of our client's business process.

Summary
While Multi-Version views support editing, the limitations are onerous, and I suspect by design (I suspect someone wants you to use a pricy ArcSomething license to edit your ArcSDE data). However, for read-only usage, they are a really powerful way to create reports against your enterprise geodatabase.

[UPDATE]
In a comment on the original post when this was on ArcDeveloper.net, Neil noted the following:

Here's some additional stuff on the objectids issues you mentioned, at least for the version of sde I'm working with - 9.1 SP1 with MSSQL 2005.

It looks like you can just leave the OBJECTID column out of the insert statement.

There is an insert trigger on the multi-version view that calls the _get_ids & _return_ids stored procedures that you mentioned to generate the objectid.