I'll disagree with you at first, and agree with you to some degree after... First and foremost, if you designed a "dependent process" around the functionality of a feature you didn't fully understand... That's on you, not Microsoft. BOL: CREATE TABLE (Transact-SQL) IDENTITY (Property)
It's not exactly hidden in the fine print... It was a design decision, between being sequential and being fast.. They chose being fast. If you're familiar with the relation model, surrogate keys exist only to uniquely identify a tuple (row of data). They aren't supposed to have ANY meany beyond that.
With that out of the way... I'll say that Microsoft has #@$% the bed on more than a few design decisions (their implementation of IDENTITY doesn't earn an honorable mention on that list)... But... I won't go down that road. I'll just say that it would have been nice had they left the fast vs sequential decision to their customers. I can't imagine that it would have been difficult to simply add an additional parameter allowing the user to specify their preference when creating a table. Simply creating a sequence object behind the scenes (without the hassle of creating one manually) would have been fine... or... given the amount of data held in memory for cached data and query plans, making room for the last identity value for every table wouldn't exactly be a burden... Meaning the "sequential" options wouldn't have to be more than a nanosecond longer than the "fast" option.
So, to sum up... I think it would be a nice option to have but it isn't a deal breaker for me. If I need an unbroken sequence, I'll use a SEQUENCE object. I'm far more concerned about the lack of inline scalar functions, the lack of GREATEST & LEAST functions, the lack of a row number on the new(ish) STRING_SPLIT and the inability to use DISTINCT in any of the windowing functions.