Now for some the gory details and minor quibbles. In function calls you can get a slightly different behaviour, and it is a judgement call about whether to think about this as there being a syntactic difference, or whether you think of the way it behaved in assignment to be the same as the function case - just with the default behaviour. I'd lean towards saying that the syntax is the same - but only functions can specify non-default behaviour.
Explaining that will take a bit.
First of all what is a list? A list is what you'd guess naively, an ordered list of things. Think of shoving a bunch of stuff on the stack - that's a list. In fact I believe that that's how Perl actually works internally, it sticks pointers to the list on the stack, and calls an operation that is supposed to do something with those arguments. When the opcode finishes, the stack is cleared. This all happens at the C-level, all actual Perl data structures are kept in the heap. They have to be because their lifetime is indeterminate when the data is created. (Note that in Perl 6 even lists will be created in the heap to allow continuations to be added to the language. This is very similar to Python vs Stackless Python.)
Arrays and hashes and most functions will accept a list and do something intelligent with it. If you assign the list to an array, the array is filled with that list, element 0 goes to element 0, element 1 goes to element 1 and so on. If you assign the list to a hash, it is interpreted as a list of key/value pairs and the hash is set up accordingly. If you call a function the elements of the list are aliased to @_, and the function is supposed to get the arguments from there.
Hopefully the idea of a list is fairly clear - it is supposed to be straightforward.
Now we come to the non-straightforward part. Normally when you call a function, everything is expanded out. So if you see something like:
\n foo(@stuff, @more_stuff, bar());\n
then foo will get a list containing everything in @stuff followed by everything in @more_stuff followed by what bar() returned. But there are exceptions. For instance:
\n push(@stuff, @more_stuff, bar());\n
adds the contents of @more_stuff and the return of bar() to the end of @stuff. The push built-in has something (mis)named a prototype that causes the generated list to be (\\@stuff, @more_stuff). You still get a list - just a slightly different one than you would expect.
This was originally shoehorned in for backwards compatibility. In Perl 1-4 these built-ins had special behaviour, and there was no good way to get the same behaviour for user-defined functions because you didn't have references. Through Perl 5 the capability to write functions that behave the same way as these special built-ins has been added. Using this capability is generally a very, very bad idea. For a full explanation of how it works, what it does, and why it is a bad idea, read [link|http://library.n0i.net/programming/perl/articles/fm_prototypes/|FMTYEWTK About Prototypes].
Now that I've explained this whole prototype thing, you see that it is possible for functions to get a slightly different list than you'd expect just looking at the argument list. However the default behaviour is, "expand everything expandable out into a flat list". If you're assigning to array you get this same default behaviour. With functions you have some control over how this list expansion works. With array assignment you don't.
Cheers,
Ben