1 - It is usually the intent of having a named numeric constant to free you from knowing what the specific value is, but we agree that there are some scenarios where you'd like to know that value. We'll keep that in mind when writing documentation.
2 - The documentation for 8 objects is invisible to Excel because in order to be visible to Excel, it has to be compiled into the DLL (simplifying things). We didn't put the documentation into the DLL for 8 because this would only work for COM objects, .NET clients wouldn't get it (.NET clients interoperate with 8 through COM and automatic conversion loses non-vital things like documentation). With 9, we have a similar problem with the reverse direction: we can put the documentation for .NET objects into the DLL, but it won't be available for COM clients. We have a couple of ideas as to how we can provide documentation in this format (suitable for use by third-party tools) for both COM and .NET, for now let's just use the website.
4 - Your screen seems to show methods and properties of the Application object. We do expose an instance of an Application object as an unnamed global for scripts, but I am not sure how Excel could find out about that, maybe 'globals' refers to something Excel-specific which happens to coincide with what we are doing for our scripts.
5 - Yes, you can script 9 through Excel. In Visual Studio, you would add a reference to EXT.DLL - that DLL contains the .NET API, but the system will convert to COM automatically (.NET can call COM and vice versa). There should be something similar in Excel.