Good post on the function of LMS, Matt. Only thing I'd add is that the xAPI statement is one unit of measure for status update from a course. A course could carry a single statement and a ton of other information within that statement using the state document. I'm finding the state doc to be really useful in keeping traffic down. The downside is the state document isn't queryable. So it really depends an awful lot on what you need to do with the data.
To the OP -
If you're getting into elearning, I'd caution against "rolling your own" solution to connect the front end with the back end. Anyone that's been around since the beginning of the industry remembers the pain caused by constant reinvention of the wheel by folks that wanted to do it themselves. This is the primary reason AICC and SCORM popped into the scene. Content wasn't portable and creating the interface between content front end and tracking back end takes a lot of work. This work does NOT scale well if you're adding a lot of content to a system and inevitably tuning it as you go.
Specifications and standards ensure that a minimum number of features are available right out of the box. Implementing SCORM and even xAPI in your own HTML package is relatively trivial compared to the amount of design and development effort you'd need to produce to match the features available in the spec.
SCORM does more than just track completion. It forms glue between the front and backend to handle tracking, state restore, capture of comments, capture of interactions (how questions are answered) and more. xAPI handles a more broad array of statement types that extend beyond the SCORM profile.
SCORM is sandboxed. Meaning that an event <> person connection launched within the LMS cannot communicate (by spec) with another event <> person connection. One person launches a course. That course isn't aware of any other course.
xAPI is relatively open. A statement can be queried from another experience and brought into a course, app, game, whatever. But it's up to you and you run the risk of building a bulk of data that is harder to manage and open to interpretation.
LMS products can be expensive but they don't need to be. Take a look at http://moodle.org and http://www.learndash.com. Both of these offer different sets of features depending on what you want to do. Moodle supports SCORM 1.2. Learndash doesn't support SCORM but does support a connector to an LRS. http://www.nextsoftwaresolutions.com/grassblade-lrs-experience-api/ is relatively inexpensive and a bit easier to configure on most hosts than something like https://learninglocker.net/. If I were you, I'd get some experience implementing both SCORM and xAPI if you're looking to get into the industry. They are specifications that are common. You'll likely find that you'll like the cleanliness of the connections made between front / back end and the power you have to trigger built in events within your wrapper of choice. The https://github.com/adlnet/xAPIWrapper is pretty straightforward. For SCORM, I've had good luck with https://pipwerks.com/downloads/ wrapper. Using the stuff built into the tool is great. But there's plenty to learn from building a simple module from scratch and connecting with something like http://cloud.scorm.com or http://www.saltbox.com/, which are both free for development scale testing.
Like anything else, looking in from the outside and saying "I could just use PPT for that, looks easy -- why do I need a tool. (silently announcing to the community you're asking for advice that you think they're fools for using custom tools and specifications)" are words you'll likely regret once you get into this work at any kind of scale.
Good luck. Embrace specifications and tools and you'll eventually have a good time with it.
