Uh..! I've been an Excel Applications Developer since 2003. That said, there's
a few things in your post I'd like to address:

Yes, Excel UI can be configured such that the user of a solution may not even
realize it's Excel under-the-hood.

No, developers of Excel-based solutions do not ship Excel with their program; -
users MUST have MS Office installed on their machine to use Excel-based
programs.

Yes, VBA can be used to code just about anything because it's based on the
Visual Basic development language which MS Office exposes its component Object
Models to. We cannot, however, access any parts of MS Office components that
are not exposed to VBA.

There's a distinct difference between an Excel Addin and an Excel Application:

Addins work within the user's default Excel UI to add enhancements and/or
extend Excel's usability for task-specific functionality;

Applications use their own instance of the default version of Excel installed
on the user's machine. Typically, these are started from a frontloader.exe
icon on the desktop, which starts its own instance of Excel and configures
its UI as desired, then turns it over to the user. Frontloaders can be written
in any program language capable of implementing Automation. I use VB6 for
mine!

Applications that 'appear' to be Excel-like most will use a spreadsheet
component inside their app as I do with my stand-alone duplicates of my
Excel-based apps. The component can be either an ActiveX control (such as the
fpSpread.ocx I use with VB6 or C# WinForms) or DotNet Assemblies (such as the
SpreadsheetGear assemblies I use with C#). These apps do not require MS Office
be installed because they have no dependancy on Excel; - all features/functions
are built into the spreadsheet control.

VBA is a product-specific macro language used to automate any product (licensed
by MS to use it) that exposes its object model to it, <not just MS Office!

(My SolidWorks CAD software uses it)

To support your claims to what VBA can do in Excel...

Re your ref to CAD/CAM hardwa
Most CNC equipment uses G-code and Basic for programming; - the syntax for this
is different than VBA's and so would definitely not compile in the VBE (ergo,
not run)! G-code programs can be written with any text editor app and so do not
require to be written in any special software environment. Ergo, it is totally
possible to write CNC programs and download them to a CNC machine once saved in
the target's file format. This could be done via VBA using a textbox control on
a userform OR automating a text editor for writing the code.

I did some work for a company that built various models of CNC milling machines
for automating processes involved with automotive engine components. Because
the models varied as to their respective capacities and toolchanger designs,
their had to be different programs written to do the same process on each
machine. This required some complex file management so same processes could use
same filenames for each machine model, but not get mixed up when downloading to
the machines before delivery. (CNC program filenames were numeric,
non-descriptive extenion-less: ie. O0000, O0001, and so on)

As a result I developed CncFiles Manager for Excel (an Addin) so they could
read/write G-code files, file properties, and manage storage for program file
distribution to the respective machine models via their network. This replaced
Excel's toolbars/menubar/context menus with its own during runtime, and
included its own CHM userguide.

This evolved to a stand-alone exe (CncFiles Pro) after I acquired the
fpSpread.ocx and some excellent file explorer controls. Its UI has a
FolderView.ocx on its left side (1/4 width of window in Maximized view or
lMinWid (constant) in Normal view; resizeable by user via a colored divider)
that's always visible, and the fpSpread.ocx beside it along with a
FileView.ocx overlaid in the same space so their visibility can be toggled
to work with program file properties or use as a file explorer. Only CNC
program files could be listed in the fpSpread.ocx where descriptive (embed)
file properties could be viewed, edited, or the files could be opened in
the user's preferred editor for revision.

They also needed a program they could distribute to sales reps for quoting the
various machine models, writing sales orders based on quotes, and submitting
purchase orders to the manufacturer. I wrote their QSP Addin for Excel to
handle this. It included a template worksheet for each model CNC machine
listing all of the tooling and optional features available for the respective
model. (AFAIK, this is still in use today) Sales reps needed to only insert a
value in the Qty field to 'flag' that line item for printing and auto-calc the
value in the Amount field. Clicking the Print button hid all lineitems not
flagged to simplify quotes/orders. This addin also replaced Excel's
toolbars/menubar/context menus with its own during runtime, and included its
own CHM userguide.

...the above addins pretty much took over the Excel UI in terms of menus,
shortcut keys, and appearance even to the point of replacing its window icon
with my addin's icon so you saw it in the taskbar during runtime.

VBA6 was replaced with VBA7 in MS Office 2010. Macros are bit-specific meaning
code must be used in the bit version it was written in.

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion