I think you're overthinking the whole asymptotic "but never reaches" aspect, that's not terribly important. Also, forget about trying to incorporate a bunch of grad-school level math, that just really isn't important here either.
Big O is just to describe how the runtime of a function grows as its input grows to be Huge™ in size. Huge™ is a sufficiently technical quantity. We programmers are regularly using the same 'tool' to work with data sets that span several orders of magnitude in size, this is something that is basically unique to this field. The same code might be use to select which choice from a vending machine, as to select one of trillions of records, (aka Huge™). In no other field does that sort of thing take place.
So, when are running our algorithm on those datasets several trillions of records in size, all the hardware quirks, constant factors, and other trivia is shaken out and becomes a rounding error compared to those resulting Big O factors. We're never going to approach infinity because we're probably never going to have harddrives the size of the solar system, so we just kinda play fast and loose and deciding when we're big enough.
When we're doing the math to actually compute the complexity of an algorithm, we can compare asymptotic aspects of each contributor to the growth to decide which are important and which are not, which can be some tricky grad-school math. But you may have intuitively realized some of it, in your comment
f(x) = 2x^2 + 4x + 30 it should be plain to recognize that as x gets Huge™ only x^2 is going to matter, and the others are rounding noise. For a simple example we can intuit that plainly, but to formally prove it in a grad-school level class we need to use limits and all the asymptotic math you're fretting about.
But to compare algorithms that have been analyzed, we don't have to think nearly as hard.