Apparently, it hasn't leared how to spell yet.

It's very possible that this is just a coincidence and that this has nothing to do with the meaning of the bits. Sure, it seems like there's no way it could be by accident that a number around 6.8 billion is prime, but there is:
The chances of a random number x being prime are about ln x. ln 6830770643 ~= 22.6, but it's possible that the first number had to be 1, which would mean (since it's palindromic) the last number has to be 1 (making the number odd), excluding 2 as a possible factor. This puts the chance at more like 11.3. It's quite possible that we're reading too much into this. This might've just been randomly picked by an artist, (and then made symmetrical by making it a palindrome) instead of designed by a geek (and intentionally including a hidden meaning or just making it a prime or something).
In searching for additional evidence that primes were an intentionally selected theme, I looked at:
11001011100100101
10100100111010011
0100100111010011
1100101110010010
(each half of the palindrome, with and without the 1 in the center)
One of these is prime: 0100100111010011_2=18899_10, 18899 is prime. I'm not sure what it means, but I doubt those substrings were chosen for their primality.

No, that's not standard usage in the US or anywhere else that I'm aware of.
It's always possible the report was not properly representing what he was trying to convey, but the report definitely shows usage that isn't clear for anyone, unless it was explained on the test. No wonder people are confused.

Granted.

While the fact remains that you can make the number large enough for it to be impractical even with GNFS, I must disagree that it makes no significant difference. If the only thing we could do was trial division by primes, a 44 digit RSA composite would need at most ~200 quintillion divisions to find the factors. (see http://primes.utm.edu/howmany.shtml, there are ~200 quintillion primes below 10^22) More than sufficient for safe encryption. Even if you could do 1 billion per second, you'd need almost 6400 years to crack it.
But since there's GNFS, a 309 digit (1024 bit) number is currently the standard, and is being phased out.

In any case, you could've said something along the lines of "There are some more efficient ways, but they are still difficult for large numbers." instead of "There are some tricks you can use to speed it up, but that's essentially it."

This is very, very wrong. What you describe is the most naive possible way to factor a number, a.k.a. trial division (without an obvious "trick" to speed it up: not bothering dividing by composites). There are far more efficient ways to factor large numbers. The fastest, currently, for numbers over about 90 digits without any easily-found smaller factors, is the General Number Field Sieve.
http://en.wikipedia.org/wiki/Integer_factorization
http://en.wikipedia.org/wiki/Trial_division
http://en.wikipedia.org/wiki/General_number_field_sieve

Sorry, no. That doesn't take into account the fact that some parts can't be run in parallel on many home computers. Not to mention that the longest part, sieving, for a number this size, needs about 1 GB of RAM free, which I'd think people would be likely to notice and shut down pretty quickly...
Sieving is the step that takes the most time, in this case 1500 CPU years ("On a single core 2.2 GHz AMD Opteron processor with 2 GB RAM per core, sieving would have taken about fifteen hundred years."), but can easily be run in parallel. Let's say you have access to 100,000 cores, each with at least 1 GB of RAM that you can use (read the PDF...). It will now take you 5.475 days to do the sieving.
Polynomial selection can, like sieving, be easily distributed, and is a relatively trivial task with 100,000 cores available. (roughly 20 CPU years, or under 2 botnet-hours, and a non-enormous amount of RAM)
The hard parts are the final steps: filtering, building a matrix, solving it, and finding the factors. You basically need one or more supercomputers to do it, with at least one of them having 1 TB of RAM and fast access to 5 TB of data. To do it like they did, you'd also need to write your own block Wiedmann implementation. If not, you'd have to use the block Lanczos, which can only be run on a single computer/supercomputer/cluster.

Doubtless, someone could botnet enough computing power to sieve for an RSA-768 key in a matter of weeks, but to actually finish it and get the factors would require an expensive supercomputer, be it purchased, (better hope whatever's behind that key is valuable...and thank goodness that they were stupid enough to use just a 768-bit key on it) botnetted, (good luck to get one and not have anyone notice!) or otherwise acquired.

What they did was factor a 768-bit number, like one that could be used as a 768-bit RSA public key. e.g. to factor 15, you need to find that it is equal to 3*5, which can be easily done by dividing the first few primes and finding that 3 divides 15. To factor a very large number, like a 768-bit number that is semiprime with the two factors both about the same size, (as is the case with RSA public keys) is a very difficult task. It is currently best done by the General Number Field Sieve (GNFS). For more info on any of these concepts, use Wikipedia.
This demonstrates the possibility of breaking any given 768-bit RSA key by factoring the public modulus, and shows how much work that takes. Note, however, that it is still very difficult, and in this case took multiple years of calendar time and hundreds of years of CPU time to crack.
This does not mean that every 768-bit RSA key can be cracked any more easily than it could before, it just demonstrates that we have the ability to crack any 768-bit RSA key (given the time and resources).