How far off was option #3?
Using solely the options you've listed I'd say the most efficient method is the one that runs the quickest and is easiest for the front-end to process (eg, the output from checktable is going to be a bit tough to process in a stored proc). ("Duh, Mark!" ?) For the 2 stored proc options I'd probably want to write my own stripped down versions that eliminate any queries/processing that's not needed specifically for your case.
--------------
However, stepping back a bit (errrr, taking a look at the bigger picture) ... What's your ultimate goal? What are you going to do with the space usage data? How accurate does the data need to be?
If you're looking for a means of sounding an alarm if the log gets 'too full' ... or if you're looking for a historical perspective of when you have peaks in log space usage ... have you considered setting up multiple thresholds on the logsegment?
Instead of constantly polling the database with your resource-intensive query (how often do you need to run your query for it to provide the necessary benefit?), you could let the database's threshold monitoring capability provide you with the data you need without the overhead of constantly running the space-calculation query.
The thresholdaction stored proc can be coded to a) automatically dump the log, b) insert the datetime/space-usage data into a table and c) send messages to the errorlog:
a) with excessive thresholds, and especially with long-running queries, you can end up re-dumping a lot of the log over and over, so you may want to add a bit of logic to insure you only dump the log for certain threshold crossings
b) with enough thresholds you can get a pretty good idea (from the historical data) of when you have spikes in log activity
c) with errorlog monitoring (eg, monitor the physical errorlog; repeated polling of the monErrorLog table) you can get warnings when the log starts to get 'too full'
At one of my current clients I've scrapped the resource-intensive polling queries in favor of using thresholds, a threshold action stored proc that auto-dumps the log (and dumps messages to the errorlog), and real-time monitoring of the errorlog (capable of sending emails and/or pages depending on environment and % of segment in use). Historical reporting isn't a big issue so I've skipped dumping the data to a table (I can always do a quick scan of the errorlog for threshold firings to get historical date/time/segment/threshold-level data). I've got 3 (or 4?) thresholds defined on every segment of every database in the dataservers I'm responsible for (a post-startup shell script assigns thresholds to all segments in all tempdbs).
Granted, the threshold 'solution' requires some initial design and infrastructure buildout but it eliminates the overhead issues of a polling-based, resource-intensive query solution (IMO). [NOTE: A good errorlog monitoring solution provides a lot of benefits above and beyond just monitoring thresholds.]