You usually want the last name separate when you want to be able to sort users alphabetically by their last name instead of their first name or nickname. But this admittedly makes less and less sense in the age of search and monster datasets.
Also: for personalized content. "Hi John" is better than "Hi John Smith" when sending email. There's a gazillion ways to fail extracting the first name when a name doesn't follow a [first] [last] name format.
1. They're separated because other data sinks you share with want them separated, like the tax office.
2. They're separated because people want to call you by your first or last name depending on the situation, and they don't want to force you to fill in every variation. What's your name; what's the name you want us to call you; what's your name we should put on any mail to you; what's your "more formal name" like we'd use if we sued you?
Addresses
2. That is often a requirement of postal offices. They're pretty amazing in that they work at all but a lot of that is because street, suburb, state, country, are often on different lines. (But of course some countries have completely and utterly different differentiations for this, too).
So why did I do this, go from what you want to something else? What was the evil marketing intent?
Those names also get used by other systems, therefore to create a support ticket in 3rd party system, extra name needed. There is also the small matter of writing back to whomever filled in the form. 'Dear Steve, thanks for applying for the position of blah blah...' becomes possible.
The backend form handling is there to build a tidy database so extra fettling goes on. Customer enters 'steve mcdonald' in the 'name' field, but when you email them their tickets you would prefer to have the name as 'Steve McDonald'. Note the titlecasing going on there and the tidying of whitespace. This is a snip if using two fields, a bit more complex otherwise.
Doing this makes it easier when it comes to customer enquiries, the name is the same in the sales order table, the customer database, the newsletter system somewhere in the cloud and in the helpdesk system. Simple.
Also important to the change was the reality of how web forms work. You can get autofill to do a good job of 'firstname' and 'lastname', it is all there to be clicked 'submit' to if the form autofill helpers are configured correctly in a HTML5 way.
Sometimes the Mr/Mrs option is helpful as you instantly get people's gender. That is why the Mr/Mrs box is there.
Personally I do not put Mr/Mrs in forms, instead I use the 'gender' library to guess the customer's gender based on their IP address (country) and their first name. In this mini-'shadow profile' the gender guess is not disclosed to the customer but it does get pulled through to the reports and the inaccuracy of not knowing whether 'Viv' is a girl or a boy does not matter in the aggregate.
So there you have it, why an 'evolved web form' can move away from a 'name' box to 'firstname' and 'lastname'.
Nothing feels as faked as a "Hey [incorrect name]!" letter, so it's probably better to avoid it.
Why do I absolutely need to be filed as [Ms] [Evil] [Z.] [Ombie]? Wouldn't [Ms Evil Z. Ombie] do?
I don't even see how a family name relates you to your own parents when it's very likely there may be a few thousands, even millions of people with your last name, and even with your own combination of two or three names.
Does it make any difference when someone is searching for you if they do a search for [Mr] [John] [Smith], rather than a [Mr John Smith]? It's only a combination of name and address that can (at best hope) to disambiguate two people with the exact same name and there's no reason to try and do that in a field-by-field manner. If you can match one string without spaces you can match n strings with n-1 spaces right?
In fact why do we absolutely need more than one line for a full address? That just causes more problems than it solves, doesn't it?